perm filename CLCLEA.1[COM,LSP] blob
sn#849844 filedate 1987-11-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00606 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00087 00002
C00088 00003 ∂23-Apr-87 1359 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue DEFVAR-INIT-TIME (Version 1)
C00093 00004 ∂23-Apr-87 1432 gls@Think.COM AREF-1D
C00095 00005 ∂23-Apr-87 1447 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
C00101 00006 ∂23-Apr-87 1453 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00104 00007 ∂23-Apr-87 2031 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
C00107 00008 ∂23-Apr-87 2150 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00110 00009 ∂23-Apr-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
C00113 00010 ∂23-Apr-87 2209 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D
C00115 00011 ∂23-Apr-87 2255 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00118 00012 ∂24-Apr-87 1326 masinter.PA@Xerox.COM Re: Issue DEFVAR-INIT-TIME (Version 1)
C00120 00013 ∂24-Apr-87 1846 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-NOT-ADJUSTABLE
C00125 00014 ∂25-Apr-87 0021 gls@think.com DELETE, SORT, ADJUST-ARRAY considered harmful
C00128 00015 ∂27-Apr-87 1151 Masinter.pa@Xerox.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
C00130 00016 ∂27-Apr-87 1312 Masinter.pa@Xerox.COM status
C00139 00017 ∂28-Apr-87 1114 KMP@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00159 00018 ∂28-Apr-87 1334 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00173 00019 ∂28-Apr-87 1916 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00178 00020 ∂28-Apr-87 2204 masinter.PA@Xerox.COM Re: Issue: PROCLAIM-LEXICAL
C00181 00021 ∂29-Apr-87 0641 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PROCLAIM-LEXICAL
C00187 00022 ∂29-Apr-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
C00196 00023 ∂29-Apr-87 0943 KMP@STONY-BROOK.SCRC.Symbolics.COM status of DEFVAR-INIT-TIME
C00199 00024 ∂29-Apr-87 1024 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00201 00025 ∂29-Apr-87 1025 KMP@STONY-BROOK.SCRC.Symbolics.COM Procedure for Steele's proposed clarifications
C00204 00026 ∂29-Apr-87 1131 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
C00208 00027 ∂29-Apr-87 1234 Pavel.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00210 00028 ∂29-Apr-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
C00217 00029 ∂29-Apr-87 1337 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY (Version 5)
C00235 00030 ∂29-Apr-87 1404 gls@Think.COM AREF-1D
C00237 00031 ∂29-Apr-87 1406 gls@think.com AREF-1D
C00239 00032 ∂29-Apr-87 1501 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
C00241 00033 ∂29-Apr-87 1722 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00246 00034 ∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
C00248 00035 ∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
C00250 00036 ∂29-Apr-87 1844 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00253 00037 ∂29-Apr-87 1926 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00258 00038 ∂29-Apr-87 1951 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00263 00039 ∂30-Apr-87 0053 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00267 00040 ∂30-Apr-87 1425 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
C00269 00041 ∂30-Apr-87 1429 Masinter.pa@Xerox.COM Re: Procedure for Steele's proposed clarifications
C00271 00042 ∂30-Apr-87 1459 Masinter.pa@Xerox.COM Re: Status of IGNORE-ERRORS
C00273 00043 ∂30-Apr-87 1502 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
C00275 00044 ∂30-Apr-87 1638 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00280 00045 ∂30-Apr-87 1818 Masinter.pa@Xerox.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00283 00046 ∂30-Apr-87 1901 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00288 00047 ∂01-May-87 1536 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00292 00048 ∂01-May-87 1656 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00303 00049 ∂01-May-87 1933 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00306 00050 ∂01-May-87 1947 FAHLMAN@C.CS.CMU.EDU ADJUST-ARRAY-NOT-ADJUSTABLE
C00308 00051 ∂01-May-87 2030 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00312 00052 ∂01-May-87 2037 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00316 00053 ∂01-May-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00319 00054 ∂01-May-87 2128 FAHLMAN@C.CS.CMU.EDU Issue DEFVAR-INIT-TIME (Version 1)
C00321 00055 ∂01-May-87 2145 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00325 00056 ∂02-May-87 0707 FAHLMAN@C.CS.CMU.EDU DELETE, SORT, ADJUST-ARRAY considered harmful
C00328 00057 ∂02-May-87 1143 FAHLMAN@C.CS.CMU.EDU IF-BODY (Version 5)
C00335 00058 ∂02-May-87 1220 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00338 00059 ∂02-May-87 1313 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00344 00060 ∂02-May-87 1324 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 2)
C00346 00061 ∂02-May-87 1340 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER (Version 2)
C00347 00062 ∂02-May-87 1616 JAR@AI.AI.MIT.EDU Is JAR on CL-CLEANUP now? Yes.
C00348 00063 ∂02-May-87 1655 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00354 00064 ∂02-May-87 1720 FAHLMAN@C.CS.CMU.EDU Is JAR on CL-CLEANUP now? Yes.
C00356 00065 ∂02-May-87 1855 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00362 00066 ∂04-May-87 1056 Masinter.pa@Xerox.COM Issue priority
C00364 00067 ∂04-May-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00375 00068 ∂04-May-87 1919 FAHLMAN@C.CS.CMU.EDU Issue priority
C00378 00069 ∂05-May-87 1416 pedersen.pa@Xerox.COM Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00382 00070 ∂10-May-87 1154 FAHLMAN@C.CS.CMU.EDU [RAM: exiting from unwind protects]
C00389 00071 ∂11-May-87 1051 RPG Draft of revised FUNCTION-TYPE
C00403 00072 ∂11-May-87 1256 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
C00415 00073 ∂11-May-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
C00422 00074 ∂11-May-87 1443 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
C00426 00075 ∂11-May-87 1502 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00431 00076 ∂11-May-87 1803 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
C00433 00077 ∂11-May-87 1807 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-STREAM
C00434 00078 ∂11-May-87 1901 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00445 00079 ∂11-May-87 1907 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00447 00080 ∂11-May-87 1940 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
C00448 00081 ∂12-May-87 0728 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00452 00082 ∂12-May-87 0930 Gregor.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00453 00083 ∂12-May-87 1158 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00459 00084 ∂12-May-87 1258 gls@Think.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00461 00085 ∂12-May-87 1430 gls@Think.COM Issue: FUNCTION-TYPE (version 3)
C00462 00086 ∂12-May-87 1456 gls@Think.COM Issue: PATHNAME-SYMBOL
C00463 00087 ∂12-May-87 1457 gls@Think.COM Issue: PATHNAME-STREAM
C00464 00088 ∂12-May-87 2104 Moon@STONY-BROOK.SCRC.Symbolics.COM [RAM: exiting from unwind protects]
C00479 00089 ∂12-May-87 2124 Moon@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00482 00090 ∂13-May-87 0012 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
C00490 00091 ∂13-May-87 0914 RPG FUNCTION-TYPE and Archives
C00493 00092 ∂13-May-87 1133 @ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM FUNCTION-TYPE, archives, and Macsyma
C00497 00093 ∂13-May-87 1626 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE and Archives
C00500 00094 ∂13-May-87 2121 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
C00508 00095 ∂13-May-87 2158 Moon@STONY-BROOK.SCRC.Symbolics.COM looping in unwind-protect cleanups
C00513 00096 ∂14-May-87 1039 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
C00517 00097 ∂14-May-87 1046 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00520 00098 ∂14-May-87 1051 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
C00522 00099 ∂15-May-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00540 00100 ∂16-May-87 0302 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00542 00101 ∂17-May-87 1447 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00549 00102 ∂17-May-87 1931 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
C00561 00103 ∂17-May-87 1944 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE and Archives
C00564 00104 ∂18-May-87 1344 gls@Think.COM Issue: PROCLAIM-LEXICAL
C00566 00105 ∂18-May-87 1529 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00568 00106 ∂19-May-87 1316 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-NEGATIVE-PARAMETERS
C00572 00107 ∂19-May-87 1739 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00580 00108 ∂19-May-87 1801 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00588 00109 ∂19-May-87 1812 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00594 00110 ∂26-May-87 1431 Masinter.pa@Xerox.COM administrative
C00597 00111 ∂28-May-87 2233 JAR,KMP@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00602 00112 ∂29-May-87 2113 Masinter.pa@Xerox.COM barrage of mail coming
C00604 00113 ∂29-May-87 2114 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
C00612 00114 ∂29-May-87 2116 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
C00617 00115 ∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Version 2)
C00624 00116 ∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 5)
C00632 00117 ∂29-May-87 2119 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00634 00118 ∂29-May-87 2119 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 4)
C00649 00119 ∂29-May-87 2121 Masinter.pa@Xerox.COM Re: Issue GC-MESSAGES (Version 1)
C00653 00120 ∂29-May-87 2121 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
C00658 00121 ∂29-May-87 2122 Masinter.pa@Xerox.COM IGNORE-ERRORS (Version 4)
C00664 00122 ∂29-May-87 2123 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
C00677 00123 ∂29-May-87 2124 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
C00681 00124 ∂29-May-87 2125 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 2)
C00687 00125 ∂29-May-87 2127 Masinter.pa@Xerox.COM Status [Part 1]
C00694 00126 ∂29-May-87 2128 Masinter.pa@Xerox.COM ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
C00698 00127 ∂29-May-87 2133 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 5)
C00703 00128 ∂29-May-87 2214 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
C00711 00129 ∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: TAILP-NIL
C00714 00130 ∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
C00716 00131 ∂29-May-87 2310 Masinter.pa@Xerox.COM Status, Part 2
C00719 00132 ∂29-May-87 2310 Masinter.pa@Xerox.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
C00721 00133 ∂30-May-87 0715 MATHIS@ADA20.ISI.EDU Re: barrage of mail coming
C00723 00134 ∂31-May-87 2051 masinter.pa@Xerox.COM ballots, meeting, etc.
C00725 00135 ∂01-Jun-87 1217 JAR@AI.AI.MIT.EDU Status, Part 2
C00727 00136 ∂01-Jun-87 1449 edsel!kent-state!eb@navajo.stanford.edu AREF-1D
C00729 00137 ∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
C00731 00138 ∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
C00736 00139 ∂01-Jun-87 1650 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00738 00140 ∂01-Jun-87 1715 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: FUNCTION-TYPE (version 4)
C00741 00141 ∂01-Jun-87 1810 Pavel.pa@Xerox.COM AREF-1D
C00742 00142 ∂01-Jun-87 1822 Pavel.pa@Xerox.COM DO-SYMBOLS-DUPLICATES
C00745 00143 ∂01-Jun-87 1830 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00747 00144 ∂01-Jun-87 2041 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TAILP-NIL
C00749 00145 ∂01-Jun-87 2047 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
C00754 00146 ∂01-Jun-87 2050 Moon@STONY-BROOK.SCRC.Symbolics.COM PATHNAME-SYMBOL
C00758 00147 ∂01-Jun-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names
C00761 00148 ∂01-Jun-87 2121 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 4)
C00764 00149 ∂01-Jun-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00766 00150 ∂01-Jun-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
C00769 00151 ∂01-Jun-87 2126 Moon@STONY-BROOK.SCRC.Symbolics.COM ***BALLOT ***
C00776 00152 ∂01-Jun-87 2137 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 3)
C00786 00153 ∂01-Jun-87 2151 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
C00788 00154 ∂01-Jun-87 2152 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
C00792 00155 ∂01-Jun-87 2209 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
C00797 00156 ∂01-Jun-87 2221 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 2)
C00803 00157 ∂02-Jun-87 0041 masinter.pa@Xerox.COM schedule
C00805 00158 ∂02-Jun-87 0226 KMP@STONY-BROOK.SCRC.Symbolics.COM *** BALLOT ***
C00813 00159 ∂02-Jun-87 1016 RPG Issue: FUNCTION-TYPE (version 4)
C00815 00160 ∂02-Jun-87 1148 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00820 00161 ∂02-Jun-87 1219 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
C00823 00162 ∂03-Jun-87 0729 gls@Think.COM ***BALLOT *** PART 1 *** My reply
C00827 00163 ∂03-Jun-87 0731 gls@Think.COM DO-SYMBOLS
C00829 00164 ∂03-Jun-87 0733 gls@Think.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
C00830 00165 ∂03-Jun-87 0749 gls@Think.COM June X3J13 meeting
C00831 00166 ∂03-Jun-87 0809 gls@think.com Transitivity of coercions
C00833 00167 ∂03-Jun-87 0926 gls@Think.COM People's names :-)
C00838 00168 ∂03-Jun-87 1101 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
C00840 00169 ∂03-Jun-87 1154 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names :-}
C00843 00170 ∂03-Jun-87 1332 gls@Think.COM DO-SYMBOLS
C00846 00171 ∂03-Jun-87 1906 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
C00850 00172 ∂03-Jun-87 2038 FAHLMAN@C.CS.CMU.EDU PATHNAME-SYMBOL
C00852 00173 ∂03-Jun-87 2104 FAHLMAN@C.CS.CMU.EDU General strategy
C00856 00174 ∂03-Jun-87 2124 FAHLMAN@C.CS.CMU.EDU Ballot, parts 1 and 2
C00862 00175 ∂03-Jun-87 2135 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
C00865 00176 ∂03-Jun-87 2145 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Version 2)
C00868 00177 ∂03-Jun-87 2201 FAHLMAN@C.CS.CMU.EDU IF-BODY
C00871 00178 ∂03-Jun-87 2232 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 4)
C00876 00179 ∂03-Jun-87 2238 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
C00878 00180 ∂04-Jun-87 0852 RPG FUNCTION-TYPE
C00880 00181 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM Format revisited
C00886 00182 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM AREF-1D (Version 3)
C00892 00183 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM Merging of committees
C00896 00184 ∂04-Jun-87 1856 MATHIS@ADA20.ISI.EDU
C00897 00185 ∂04-Jun-87 1925 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 3)
C00899 00186 ∂04-Jun-87 1933 KMP@STONY-BROOK.SCRC.Symbolics.COM Merging of committees
C00903 00187 ∂05-Jun-87 1808 Masinter.pa@Xerox.COM FORMAT-OP-C (Version 4)
C00912 00188 ∂05-Jun-87 1809 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C00914 00189 ∂05-Jun-87 1809 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
C00926 00190 ∂05-Jun-87 2113 KMP@STONY-BROOK.SCRC.Symbolics.COM Sigh -- More procedure
C00934 00191 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM Re: Sigh -- More procedure
C00938 00192 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C00947 00193 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM AREF-1D (Version 4)
C00953 00194 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM proposal format (version 10)
C00959 00195 ∂05-Jun-87 2210 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
C00968 00196 ∂05-Jun-87 2235 Masinter.pa@Xerox.COM Re: proposal format (version 10)
C00970 00197 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
C00975 00198 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
C00980 00199 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
C00985 00200 ∂05-Jun-87 2349 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C00992 00201 ∂06-Jun-87 0000 Masinter.pa@Xerox.COM ***READ ME FIRST ***Status
C01005 00202 ∂06-Jun-87 1412 RPG A Hole in Common Lisp
C01013 00203 ∂06-Jun-87 1630 RPG FUNCTION-TYPE
C01015 00204 ∂06-Jun-87 1802 FAHLMAN@C.CS.CMU.EDU A Hole in Common Lisp
C01022 00205 ∂07-Jun-87 0826 FAHLMAN@C.CS.CMU.EDU Rules
C01025 00206 ∂07-Jun-87 1150 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C01032 00207 ∂07-Jun-87 1259 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C01035 00208 ∂07-Jun-87 1318 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C01038 00209 ∂07-Jun-87 1348 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C01041 00210 ∂07-Jun-87 1603 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 4)
C01043 00211 ∂07-Jun-87 1612 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
C01045 00212 ∂07-Jun-87 1622 RPG Hole
C01047 00213 ∂07-Jun-87 1630 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01051 00214 ∂07-Jun-87 1632 RPG FUNCTION-TYPE
C01053 00215 ∂07-Jun-87 1648 RPG FUNCTION-TYPE and EuLisp
C01055 00216 ∂07-Jun-87 1753 FAHLMAN@C.CS.CMU.EDU AREF-1D (Version 4)
C01056 00217 ∂07-Jun-87 1755 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Version 6)
C01057 00218 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Version 6)
C01058 00219 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: DEFVAR-INITIALIZATION (Version 4)
C01059 00220 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C01060 00221 ∂08-Jun-87 0646 gls@Think.COM FORMAT-OP-C (Version 4)
C01061 00222 ∂08-Jun-87 0727 gls@Think.COM Hole
C01065 00223 ∂08-Jun-87 0802 FAHLMAN@C.CS.CMU.EDU Hole
C01067 00224 ∂08-Jun-87 1128 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 1)
C01075 00225 ∂08-Jun-87 1240 RPG Hole
C01077 00226 ∂08-Jun-87 1342 FAHLMAN@C.CS.CMU.EDU Hole
C01080 00227 ∂08-Jun-87 2001 FAHLMAN@C.CS.CMU.EDU Issue: LOAD-TIME-EVAL (Version 1)
C01083 00228 ∂08-Jun-87 2126 KMP@STONY-BROOK.SCRC.Symbolics.COM LOAD-TIME-EVAL
C01086 00229 ∂09-Jun-87 1732 Masinter.pa@Xerox.COM procedural, errors.
C01089 00230 ∂09-Jun-87 1822 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01091 00231 ∂09-Jun-87 1835 KMP@STONY-BROOK.SCRC.Symbolics.COM procedural, errors.
C01093 00232 ∂09-Jun-87 1838 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01095 00233 ∂09-Jun-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: LOAD-TIME-EVAL (Version 1)
C01102 00234 ∂09-Jun-87 2029 Moon@STONY-BROOK.SCRC.Symbolics.COM Hole
C01105 00235 ∂09-Jun-87 2113 Moon@STONY-BROOK.SCRC.Symbolics.COM A Hole in Common Lisp
C01109 00236 ∂09-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
C01114 00237 ∂10-Jun-87 1212 Pavel.pa@Xerox.COM Issue: FORMAT-COMMA-INTERVAL
C01120 00238 ∂10-Jun-87 1357 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Issue: FORMAT-COMMA-INTERVAL
C01122 00239 ∂10-Jun-87 1650 FAHLMAN@C.CS.CMU.EDU Issue: FORMAT-COMMA-INTERVAL
C01124 00240 ∂10-Jun-87 1906 Pavel.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
C01126 00241 ∂10-Jun-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01130 00242 ∂10-Jun-87 2129 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C01134 00243 ∂10-Jun-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C01136 00244 ∂10-Jun-87 2131 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
C01139 00245 ∂10-Jun-87 2325 RPG Put Up or Shut Up
C01142 00246 ∂11-Jun-87 0958 kempf%hplabsc@hplabs.HP.COM Re: Issue: LOAD-TIME-EVAL (Version 1)
C01153 00247 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
C01155 00248 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
C01156 00249 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
C01169 00250 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
C01171 00251 ∂11-Jun-87 1726 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
C01175 00252 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Status
C01188 00253 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
C01190 00254 ∂11-Jun-87 1846 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01192 00255 ∂11-Jun-87 2045 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D (Version 2)
C01195 00256 ∂11-Jun-87 2121 FAHLMAN@C.CS.CMU.EDU Status
C01197 00257 ∂12-Jun-87 0939 Masinter.pa@Xerox.COM Re: Hm
C01199 00258 ∂12-Jun-87 1040 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01204 00259 ∂12-Jun-87 1906 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE
C01206 00260 ∂12-Jun-87 1943 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-DISPLACEMENT
C01209 00261 ∂12-Jun-87 2255 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01212 00262 ∂12-Jun-87 2256 Masinter.pa@Xerox.COM Issue: EVAL-DEFEATS-LINKER
C01223 00263 ∂13-Jun-87 0042 edsel!bhopal!jonl@navajo.stanford.edu Hm
C01226 00264 ∂14-Jun-87 1136 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
C01231 00265 ∂15-Jun-87 1919 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C01233 00266 ∂15-Jun-87 1920 Masinter.pa@Xerox.COM READ TODAY: Cover letter for mailing to X3J13
C01246 00267 ∂15-Jun-87 1938 FAHLMAN@C.CS.CMU.EDU READ TODAY: Cover letter for mailing to X3J13
C01250 00268 ∂15-Jun-87 2042 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: EVAL-DEFEATS-LINKER
C01259 00269 ∂15-Jun-87 2140 Moon@STONY-BROOK.SCRC.Symbolics.COM READ TODAY: Cover letter for mailing to X3J13
C01262 00270 ∂16-Jun-87 0159 Masinter.pa@Xerox.COM Re: READ TODAY: Cover letter for mailing to X3J13
C01266 00271 ∂16-Jun-87 0608 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 5)
C01292 00272 ∂16-Jun-87 1338 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C01299 00273 ∂16-Jun-87 1945 edsel!bhopal!jonl@navajo.stanford.edu READ TODAY: Cover letter for mailing to X3J13
C01301 00274 ∂16-Jun-87 2040 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
C01307 00275 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 5)
C01309 00276 ∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
C01313 00277 ∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C01316 00278 ∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C01320 00279 ∂17-Jun-87 1941 edsel!bhopal!jonl@navajo.stanford.edu Issue: EVAL-DEFEATS-LINKER
C01325 00280 ∂18-Jun-87 1126 RPG FUNCTION-TYPE (Version 5)
C01326 00281 ∂18-Jun-87 1132 RPG FUNCTION-TYPE (Version 5)
C01327 00282 ∂19-Jun-87 1429 @RELAY.CS.NET:willc@tekchips.tek.com Re: Issue: EVAL-DEFEATS-LINKER
C01336 00283 ∂19-Jun-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
C01341 00284 ∂22-Jun-87 2236 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
C01347 00285 ∂23-Jun-87 0809 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01350 00286 ∂23-Jun-87 0948 edsel!kent-state!eb@navajo.stanford.edu Issue: FUNCTION-TYPE (Version 5)
C01354 00287 ∂23-Jun-87 1145 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
C01359 00288 ∂23-Jun-87 1538 RAM@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01366 00289 ∂25-Jun-87 2333 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE: not allowing symbols to be used as functions
C01368 00290 ∂26-Jun-87 1104 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Issue: IF-BODY (Version 7)
C01370 00291 ∂29-Jun-87 2239 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-DOCUMENTATION (Version 1)
C01374 00292 ∂06-Jul-87 1658 Masinter.pa@Xerox.COM AREF-1D (Version 6)
C01381 00293 ∂13-Jul-87 1257 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01383 00294 ∂13-Jul-87 1321 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01391 00295 ∂13-Jul-87 1344 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01399 00296 ∂13-Jul-87 1415 Masinter.pa@Xerox.COM Status
C01413 00297 ∂15-Jul-87 1329 Masinter.pa@Xerox.COM Issue: Pathname-subdirectory-list
C01419 00298 ∂16-Jul-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: Pathname-subdirectory-list
C01426 00299 ∂16-Jul-87 1730 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01428 00300 ∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
C01433 00301 ∂23-Jul-87 1735 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 2)
C01441 00302 ∂23-Jul-87 1735 Masinter.pa@Xerox.COM Status, clarification list, members
C01443 00303 ∂24-Jul-87 1024 KMP@STONY-BROOK.SCRC.Symbolics.COM OPEN-KEYWORDS
C01447 00304 ∂24-Jul-87 1038 KMP@STONY-BROOK.SCRC.Symbolics.COM Mail from Skona Brittain
C01453 00305 ∂27-Jul-87 1005 KMP@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
C01458 00306 ∂27-Jul-87 1754 FAHLMAN@C.CS.CMU.EDU APPEND-DOTTED
C01459 00307 ∂27-Jul-87 1802 FAHLMAN@C.CS.CMU.EDU [Fahlman: Iteration standard]
C01464 00308 ∂30-Jul-87 1129 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01467 00309 ∂30-Jul-87 1145 FAHLMAN@C.CS.CMU.EDU Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01469 00310 ∂30-Jul-87 1717 Masinter.pa@Xerox.COM Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01472 00311 ∂31-Jul-87 1833 edsel!bhopal!jonl@labrea.stanford.edu Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01474 00312 ∂05-Aug-87 1931 Moon@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
C01475 00313 ∂14-Aug-87 1651 unido!ztivax!kolb@seismo.CSS.GOV Redefinition of system functions
C01479 00314 ∂14-Aug-87 2055 FAHLMAN@C.CS.CMU.EDU Redefinition of system functions
C01482 00315 ∂24-Aug-87 1138 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 1)
C01488 00316 ∂24-Aug-87 1808 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 1)
C01490 00317 ∂27-Aug-87 1429 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 2)
C01499 00318 ∂29-Aug-87 1337 Masinter.pa@Xerox.COM [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01504 00319 ∂29-Aug-87 1439 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01509 00320 ∂02-Sep-87 1926 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01511 00321 ∂02-Sep-87 1952 FAHLMAN@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01514 00322 ∂03-Sep-87 1118 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01517 00323 ∂04-Sep-87 1030 edsel!bhopal!jonl@labrea.stanford.edu [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01521 00324 ∂04-Sep-87 1047 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01526 00325 ∂21-Sep-87 1436 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01532 00326 ∂21-Sep-87 1957 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01536 00327 ∂22-Sep-87 0756 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01543 00328 ∂22-Sep-87 0854 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01547 00329 ∂22-Sep-87 0905 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01549 00330 ∂22-Sep-87 1253 Masinter.pa@Xerox.COM Re: APPEND-DOTTED
C01551 00331 ∂22-Sep-87 1254 Masinter.pa@Xerox.COM [remailed] Re: APPEND-DOTTED
C01553 00332 ∂22-Sep-87 1300 dcm%hpfclp@hplabs.HP.COM Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
C01556 00333 ∂22-Sep-87 1303 Masinter.pa@Xerox.COM Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01558 00334 ∂22-Sep-87 1306 Masinter.pa@Xerox.COM Re: Issue: EVAL-DEFEATS-LINKER
C01560 00335 ∂22-Sep-87 1347 FAHLMAN@C.CS.CMU.EDU [remailed] Re: APPEND-DOTTED
C01562 00336 ∂22-Sep-87 1434 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01565 00337 ∂22-Sep-87 1434 Masinter.pa@Xerox.COM Status
C01586 00338 ∂22-Sep-87 1434 Masinter.pa@Xerox.COM Status
C01607 00339 ∂22-Sep-87 1513 Masinter.pa@Xerox.COM status: remaining ISSUES.TXT file
C01663 00340 ∂22-Sep-87 1929 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01668 00341 ∂26-Sep-87 1740 Masinter.pa@Xerox.COM reply to yuasa message
C01671 00342 ∂26-Sep-87 2000 gls@Think.COM reply to yuasa message
C01672 00343 ∂26-Sep-87 2030 FAHLMAN@C.CS.CMU.EDU reply to yuasa message
C01673 00344 ∂28-Sep-87 0910 Moon@STONY-BROOK.SCRC.Symbolics.COM reply to yuasa message
C01675 00345 ∂08-Oct-87 1655 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 4)
C01680 00346 ∂09-Oct-87 0927 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 4)
C01682 00347 ∂09-Oct-87 0927 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 4)
C01684 00348 ∂09-Oct-87 1408 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
C01687 00349 ∂09-Oct-87 1419 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
C01690 00350 ∂09-Oct-87 1457 Masinter.pa@Xerox.COM Issue: STREAM-CLASS-ACCESS
C01693 00351 ∂09-Oct-87 1524 Masinter.pa@Xerox.COM Issue: DEFINITION-FUNCTIONS
C01701 00352 ∂09-Oct-87 1524 Masinter.pa@Xerox.COM Issue Status (reply solicited)
C01724 00353 ∂15-Oct-87 1411 @STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
C01741 00354 ∂15-Oct-87 1725 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
C01745 00355 ∂15-Oct-87 1738 Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
C01749 00356 ∂15-Oct-87 1746 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
C01751 00357 ∂16-Oct-87 0107 peck@Sun.COM Re: Issue: PUSH-EVALUATION-ORDER
C01761 00358 ∂16-Oct-87 0936 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PUSH-EVALUATION-ORDER
C01764 00359 ∂16-Oct-87 1106 sandra%orion@cs.utah.edu compile-time effects of top-level forms
C01778 00360 ∂16-Oct-87 1107 sandra%orion@cs.utah.edu proposal for modifying behavior of REQUIRE
C01787 00361 ∂18-Oct-87 1959 FAHLMAN@C.CS.CMU.EDU Issue: DEFINITION-FUNCTIONS
C01789 00362 ∂18-Oct-87 2021 FAHLMAN@C.CS.CMU.EDU compile-time effects of top-level forms
C01791 00363 ∂19-Oct-87 0731 sandra%orion@cs.utah.edu Re: compile-time effects of top-level forms
C01794 00364 ∂19-Oct-87 0801 FAHLMAN@C.CS.CMU.EDU compile-time effects of top-level forms
C01797 00365 ∂20-Oct-87 1208 KMP@STONY-BROOK.SCRC.Symbolics.COM :1
C01799 00366 ∂20-Oct-87 1224 RAM@C.CS.CMU.EDU :1
C01801 00367 ∂20-Oct-87 1240 KMP@STONY-BROOK.SCRC.Symbolics.COM :1
C01803 00368 ∂20-Oct-87 1247 Masinter.pa@Xerox.COM Re: :1
C01805 00369 ∂20-Oct-87 1350 gls@Think.COM :1
C01809 00370 ∂20-Oct-87 1424 Moon@STONY-BROOK.SCRC.Symbolics.COM :1
C01813 00371 ∂21-Oct-87 1444 Masinter.pa@Xerox.COM Issue: TRACE-FUNCTION-ONLY
C01823 00372 ∂21-Oct-87 1741 FAHLMAN@C.CS.CMU.EDU Issue: TRACE-FUNCTION-ONLY
C01828 00373 ∂21-Oct-87 1752 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TRACE-FUNCTION-ONLY
C01834 00374 ∂22-Oct-87 0741 KMP@STONY-BROOK.SCRC.Symbolics.COM DECLARE-MACROS (Version 1)
C01845 00375 ∂22-Oct-87 1150 Pavel.pa@Xerox.COM Re: DECLARE-MACROS (Version 1)
C01847 00376 ∂22-Oct-87 1224 FAHLMAN@C.CS.CMU.EDU DECLARE-MACROS (Version 1)
C01849 00377 ∂22-Oct-87 1259 KMP@STONY-BROOK.SCRC.Symbolics.COM COLON-NUMBER (Version 1)
C01854 00378 ∂22-Oct-87 1303 FAHLMAN@C.CS.CMU.EDU COLON-NUMBER (Version 1)
C01856 00379 ∂22-Oct-87 1358 Moon@STONY-BROOK.SCRC.Symbolics.COM COLON-NUMBER (Version 1)
C01858 00380 ∂22-Oct-87 1631 Masinter.pa@Xerox.COM administrivia
C01860 00381 ∂22-Oct-87 1645 Masinter.pa@Xerox.COM Re: DECLARE-MACROS (Version 1)
C01862 00382 ∂22-Oct-87 1716 Masinter.pa@Xerox.COM Re: Issue: TRACE-FUNCTION-ONLY
C01866 00383 ∂22-Oct-87 1716 Masinter.pa@Xerox.COM Re: COLON-NUMBER (Version 1)
C01868 00384 ∂22-Oct-87 1732 Masinter.pa@Xerox.COM Re: Issue: DEFINITION-FUNCTIONS
C01871 00385 ∂22-Oct-87 1738 Masinter.pa@Xerox.COM Issue: REQUIRE-PATHNAME-DEFAULTS
C01873 00386 ∂22-Oct-87 1757 Masinter.pa@Xerox.COM Re: SETF-FUNCTION-VS-MACRO (Version 1)
C01876 00387 ∂22-Oct-87 1840 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: SETF-FUNCTION-VS-MACRO (Version 1)
C01878 00388 ∂22-Oct-87 1900 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: REQUIRE-PATHNAME-DEFAULTS
C01882 00389 ∂22-Oct-87 2136 sandra%orion@cs.utah.edu Re: Issue: REQUIRE-PATHNAME-DEFAULTS
C01885 00390 ∂23-Oct-87 0709 gls@Think.COM COLON-NUMBER (Version 1)
C01887 00391 ∂23-Oct-87 0717 gls@Think.COM DECLARE-MACROS (Version 1)
C01889 00392 ∂23-Oct-87 0829 @Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM Re: Issue: TRACE-FUNCTION-ONLY
C01897 00393 ∂23-Oct-87 0957 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 5)
C01904 00394 ∂23-Oct-87 1036 Masinter.pa@Xerox.COM Issue: PUSH-EVALUATION-ORDER (Version 2)
C01914 00395 ∂23-Oct-87 1046 RAM@C.CS.CMU.EDU Issue: PATHNAME-STREAM (Version 5)
C01919 00396 ∂23-Oct-87 1134 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PATHNAME-STREAM (Version 4)
C01924 00397 ∂23-Oct-87 1147 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 6)
C01946 00398 ∂23-Oct-87 1153 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 6)
C01968 00399 ∂23-Oct-87 1201 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 5)
C01975 00400 ∂23-Oct-87 1205 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
C01977 00401 ∂23-Oct-87 1219 @Score.Stanford.EDU:dcm%hpfclp@hplabs.HP.COM Re: Issue: FUNCTION-TYPE (Version 6)
C01979 00402 ∂23-Oct-87 1359 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 12)
C01986 00403 ∂23-Oct-87 1411 Masinter.pa@Xerox.COM registry of *features* names
C01988 00404 ∂23-Oct-87 1436 Gregor.pa@Xerox.COM SETF-FUNCTION-VS-MACRO (Version 1)
C01993 00405 ∂23-Oct-87 1514 Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
C01999 00406 ∂23-Oct-87 1526 Masinter.pa@Xerox.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
C02009 00407 ∂23-Oct-87 1635 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 3)
C02018 00408 ∂23-Oct-87 1700 Masinter.pa@Xerox.COM Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
C02020 00409 ∂23-Oct-87 1716 Masinter.pa@Xerox.COM Environment-arguments, MACRO-FUNCTION-ENVIRONMENT
C02023 00410 ∂23-Oct-87 1728 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
C02036 00411 ∂23-Oct-87 1748 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
C02038 00412 ∂24-Oct-87 1730 Masinter.pa@Xerox.COM Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02058 00413 ∂24-Oct-87 1752 Masinter.pa@Xerox.COM Issue Status
C02082 00414 ∂24-Oct-87 1757 Pavel.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02084 00415 ∂25-Oct-87 1331 RAM@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02091 00416 ∂25-Oct-87 1350 FAHLMAN@C.CS.CMU.EDU Issue: REQUIRE-PATHNAME-DEFAULTS
C02093 00417 ∂25-Oct-87 1430 FAHLMAN@C.CS.CMU.EDU Issue: TRACE-FUNCTION-ONLY
C02099 00418 ∂25-Oct-87 1502 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 6)
C02102 00419 ∂25-Oct-87 1639 FAHLMAN@C.CS.CMU.EDU registry of *features* names
C02106 00420 ∂25-Oct-87 1650 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
C02109 00421 ∂25-Oct-87 1728 FAHLMAN@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02111 00422 ∂26-Oct-87 0935 Moon@ALLEGHENY.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
C02113 00423 ∂26-Oct-87 0939 EWeaver.pa@Xerox.COM [Moon: Issue: Pathname-subdirectory-list]
C02117 00424 ∂26-Oct-87 1050 gls@Think.COM Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02120 00425 ∂26-Oct-87 1157 Masinter.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02123 00426 ∂26-Oct-87 1413 Masinter.pa@Xerox.COM Issue: PATHNAME-SUBDIRECTORY-LIST
C02125 00427 ∂26-Oct-87 1413 Masinter.pa@Xerox.COM Re: registry of *features* names
C02127 00428 ∂26-Oct-87 1458 Daniels.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02129 00429 ∂26-Oct-87 1459 Masinter.pa@Xerox.COM Re: Issue: TRACE-FUNCTION-ONLY
C02131 00430 ∂26-Oct-87 1616 RAM@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02134 00431 ∂26-Oct-87 1637 Masinter.pa@Xerox.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
C02147 00432 ∂26-Oct-87 1655 Masinter.pa@Xerox.COM SETF-FUNCTION-VS-MACRO (Version 2)
C02166 00433 ∂26-Oct-87 1701 Masinter.pa@Xerox.COM Issue: SHADOW-ALREADY-PRESENT (version 3)
C02175 00434 ∂26-Oct-87 1721 Masinter.pa@Xerox.COM *FEATURES*, system package name
C02178 00435 ∂26-Oct-87 1738 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
C02180 00436 ∂26-Oct-87 1738 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 3)
C02182 00437 ∂26-Oct-87 1741 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 3)
C02183 00438 ∂26-Oct-87 1742 @Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM Re: Issue: TRACE-FUNCTION-ONLY
C02192 00439 ∂26-Oct-87 1831 Pedersen.pa@Xerox.COM Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
C02195 00440 ∂27-Oct-87 0933 CL-Cleanup-mailer TRACE Proposal (Version 2)
C02205 00441 ∂27-Oct-87 1307 CL-Cleanup-mailer TRACE Proposal (Version 2)
C02212 00442 ∂27-Oct-87 1334 CL-Cleanup-mailer Re: TRACE Proposal (Version 2)
C02215 00443 ∂27-Oct-87 1342 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
C02236 00444 ∂27-Oct-87 1450 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02251 00445 ∂27-Oct-87 1901 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02253 00446 ∂27-Oct-87 2015 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
C02258 00447 ∂28-Oct-87 0705 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
C02263 00448 ∂28-Oct-87 0926 CL-Cleanup-mailer TRACE Proposal (Version 3)
C02275 00449 ∂28-Oct-87 1307 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY
C02278 00450 ∂28-Oct-87 1321 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02280 00451 ∂28-Oct-87 1413 CL-Cleanup-mailer My silence
C02282 00452 ∂28-Oct-87 2111 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
C02287 00453 ∂29-Oct-87 0814 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY
C02292 00454 ∂29-Oct-87 1048 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
C02297 00455 ∂29-Oct-87 1200 CL-Cleanup-mailer Issue names
C02300 00456 ∂29-Oct-87 1241 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
C02308 00457 ∂29-Oct-87 2102 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
C02315 00458 ∂29-Oct-87 2203 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
C02316 00459 ∂30-Oct-87 0820 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
C02329 00460 ∂30-Oct-87 0932 CL-Cleanup-mailer REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02358 00461 ∂30-Oct-87 1117 CL-Cleanup-mailer Re: APPEND-DOTTED (Version 2)
C02359 00462 ∂30-Oct-87 1150 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02363 00463 ∂30-Oct-87 1154 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02365 00464 ∂30-Oct-87 1206 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
C02367 00465 ∂30-Oct-87 1307 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02369 00466 ∂30-Oct-87 1854 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
C02371 00467 ∂30-Oct-87 1917 CL-Cleanup-mailer REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02374 00468 ∂31-Oct-87 1653 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02378 00469 ∂02-Nov-87 1241 CL-Cleanup-mailer visit, Professor Takayasu Ito
C02380 00470 ∂02-Nov-87 1714 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02398 00471 ∂02-Nov-87 1918 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02403 00472 ∂02-Nov-87 1953 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02410 00473 ∂03-Nov-87 0859 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02417 00474 ∂03-Nov-87 1106 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02425 00475 ∂03-Nov-87 1315 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02435 00476 ∂03-Nov-87 1909 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
C02437 00477 ∂03-Nov-87 1938 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
C02439 00478 ∂04-Nov-87 0907 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02446 00479 ∂04-Nov-87 1125 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
C02458 00480 ∂04-Nov-87 1126 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (version 3)
C02478 00481 ∂04-Nov-87 1138 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
C02490 00482 ∂04-Nov-87 1148 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
C02497 00483 ∂04-Nov-87 1449 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02501 00484 ∂04-Nov-87 2045 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
C02504 00485 ∂08-Nov-87 1119 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 3)
C02506 00486 ∂08-Nov-87 1133 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
C02509 00487 ∂08-Nov-87 1154 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02512 00488 ∂08-Nov-87 1207 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
C02516 00489 ∂08-Nov-87 1220 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 2)
C02522 00490 ∂08-Nov-87 1242 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 3)
C02534 00491 ∂08-Nov-87 1307 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C02549 00492 ∂08-Nov-87 1334 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 6)
C02552 00493 ∂08-Nov-87 1351 CL-Cleanup-mailer Issue: PATHNAME-STREAM (Version 5)
C02556 00494 ∂09-Nov-87 0900 CL-Cleanup-mailer Issue Status
C02564 00495 ∂09-Nov-87 1032 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 3)
C02566 00496 ∂09-Nov-87 1045 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 3)
C02568 00497 ∂09-Nov-87 1055 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
C02571 00498 ∂09-Nov-87 1058 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
C02574 00499 ∂09-Nov-87 1109 CL-Cleanup-mailer OPEN-KEYWORDS
C02579 00500 ∂09-Nov-87 1122 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
C02583 00501 ∂09-Nov-87 1153 CL-Cleanup-mailer Re: OPEN-KEYWORDS
C02585 00502 ∂09-Nov-87 1313 CL-Cleanup-mailer Re: Issue: PATHNAME-STREAM (Version 5)
C02589 00503 ∂09-Nov-87 1317 CL-Cleanup-mailer Re: OPEN-KEYWORDS
C02591 00504 ∂09-Nov-87 1412 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 7)
C02613 00505 ∂09-Nov-87 1412 CL-Cleanup-mailer Issue Status
C02615 00506 ∂09-Nov-87 1557 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 5)
C02629 00507 ∂09-Nov-87 1558 CL-Cleanup-mailer DECLARE-MACROS (Version 2)
C02640 00508 ∂09-Nov-87 1622 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
C02643 00509 ∂09-Nov-87 1711 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02646 00510 ∂09-Nov-87 1720 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C02649 00511 ∂09-Nov-87 1738 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 3)
C02651 00512 ∂09-Nov-87 1903 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C02654 00513 ∂09-Nov-87 1918 CL-Cleanup-mailer OPEN-KEYWORDS
C02661 00514 ∂09-Nov-87 1955 CL-Cleanup-mailer DECLARE-MACROS (Version 2)
C02665 00515 ∂10-Nov-87 1220 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02669 00516 ∂10-Nov-87 1255 CL-Cleanup-mailer Re: Issue: PATHNAME-SYMBOL (Version 3)
C02672 00517 ∂10-Nov-87 1320 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
C02675 00518 ∂10-Nov-87 2348 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
C02683 00519 ∂10-Nov-87 2359 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
C02692 00520 ∂11-Nov-87 0133 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02706 00521 ∂11-Nov-87 0133 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
C02715 00522 ∂11-Nov-87 0149 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02721 00523 ∂11-Nov-87 0207 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 2)
C02723 00524 ∂11-Nov-87 0217 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 2)
C02725 00525 ∂11-Nov-87 0249 CL-Cleanup-mailer Issue status
C02746 00526 ∂11-Nov-87 0618 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02751 00527 ∂11-Nov-87 0844 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
C02766 00528 ∂11-Nov-87 0929 CL-Cleanup-mailer Issue status
C02789 00529 ∂11-Nov-87 1020 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
C02793 00530 ∂11-Nov-87 1213 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02795 00531 ∂11-Nov-87 1224 CL-Cleanup-mailer Re: Issue status
C02796 00532 ∂11-Nov-87 1245 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02800 00533 ∂11-Nov-87 1338 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS
C02802 00534 ∂11-Nov-87 1549 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
C02804 00535 ∂11-Nov-87 1644 CL-Cleanup-mailer meeting time
C02806 00536 ∂11-Nov-87 1701 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS
C02809 00537 ∂12-Nov-87 1520 CL-Cleanup-mailer meeting time
C02811 00538 ∂12-Nov-87 1537 CL-Cleanup-mailer Re: Issue: PATHNAME-STREAM (Version 5)
C02814 00539 ∂12-Nov-87 1704 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
C02819 00540 ∂12-Nov-87 1705 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
C02822 00541 ∂12-Nov-87 1705 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
C02825 00542 ∂12-Nov-87 1815 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
C02828 00543 ∂12-Nov-87 1815 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02832 00544 ∂12-Nov-87 1815 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
C02835 00545 ∂12-Nov-87 1815 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
C02840 00546 ∂12-Nov-87 1843 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
C02845 00547 ∂12-Nov-87 1845 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
C02847 00548 ∂12-Nov-87 1845 CL-Cleanup-mailer Re: Issue: PATHNAME-SYMBOL (Version 3)
C02850 00549 ∂12-Nov-87 1845 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
C02851 00550 ∂12-Nov-87 1848 CL-Cleanup-mailer Re: meeting time
C02853 00551 ∂14-Nov-87 0301 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02856 00552 ∂14-Nov-87 1340 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02861 00553 ∂14-Nov-87 1539 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 3)
C02868 00554 ∂14-Nov-87 1600 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 8)
C02886 00555 ∂14-Nov-87 1606 CL-Cleanup-mailer Issue Status -- Summary of KMP's positions
C02894 00556 ∂14-Nov-87 1616 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 3)
C02900 00557 ∂15-Nov-87 0305 CL-Cleanup-mailer Issue: PATHNAME-STREAM (Version 6)
C02908 00558 ∂15-Nov-87 0306 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 5)
C02924 00559 ∂15-Nov-87 0306 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 4)
C02938 00560 ∂15-Nov-87 0306 CL-Cleanup-mailer Issue status
C02961 00561 ∂15-Nov-87 1239 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02966 00562 ∂15-Nov-87 1853 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 8)
C02968 00563 ∂15-Nov-87 1926 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02970 00564 ∂15-Nov-87 2257 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02974 00565 ∂16-Nov-87 0723 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02978 00566 ∂17-Nov-87 1237 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
C02982 00567 ∂19-Nov-87 1340 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02985 00568 ∂19-Nov-87 1425 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C02989 00569 ∂19-Nov-87 1807 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
C03048 00570 ∂19-Nov-87 2102 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C03051 00571 ∂20-Nov-87 1114 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
C03060 00572 ∂20-Nov-87 1148 CL-Cleanup-mailer meeting report, Issue status
C03062 00573 ∂20-Nov-87 1149 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
C03063 00574 ∂20-Nov-87 1220 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 2)
C03068 00575 ∂20-Nov-87 1235 CL-Cleanup-mailer Proposal Format (Version 13)
C03075 00576 ∂20-Nov-87 1311 CL-Cleanup-mailer Re: Issue: ASSOC-RASSOC-IF-KEY (Version 2)
C03076 00577 ∂20-Nov-87 1331 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 3)
C03081 00578 ∂23-Nov-87 1205 CL-Cleanup-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
C03090 00579 ∂23-Nov-87 1227 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
C03098 00580 ∂23-Nov-87 1227 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
C03106 00581 ∂23-Nov-87 1245 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C03112 00582 ∂23-Nov-87 1300 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 4)
C03117 00583 ∂23-Nov-87 1306 CL-Cleanup-mailer Re: DECLARE-MACROS (Version 2) Volunteer wanted.
C03120 00584 ∂23-Nov-87 1319 CL-Cleanup-mailer Re: DECLARE-MACROS (Version 2) Volunteer wanted.
C03122 00585 ∂23-Nov-87 1326 CL-Cleanup-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
C03127 00586 ∂23-Nov-87 1403 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C03133 00587 ∂23-Nov-87 1442 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE (Version 8)
C03136 00588 ∂23-Nov-87 1443 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C03138 00589 ∂23-Nov-87 1602 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
C03141 00590 ∂23-Nov-87 1740 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 4)
C03151 00591 ∂23-Nov-87 1803 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 4)
C03153 00592 ∂23-Nov-87 1811 CL-Cleanup-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
C03155 00593 ∂23-Nov-87 1815 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
C03157 00594 ∂23-Nov-87 1818 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C03158 00595 ∂23-Nov-87 1824 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
C03161 00596 ∂23-Nov-87 1825 CL-Cleanup-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
C03162 00597 ∂23-Nov-87 1830 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 4)
C03164 00598 ∂23-Nov-87 1839 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C03165 00599 ∂24-Nov-87 1244 CL-Cleanup-mailer Issue: KEYWORD-KEYWORDS (Version 1)
C03173 00600 ∂24-Nov-87 1337 CL-Cleanup-mailer Re: Issue: DEFVAR-DOCUMENTATION (Version 2)
C03175 00601 ∂24-Nov-87 1920 CL-Cleanup-mailer Issue: KEYWORD-KEYWORDS (Version 1)
C03177 00602 ∂25-Nov-87 0917 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT
C03182 00603 ∂25-Nov-87 1547 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 5)
C03185 00604 ∂25-Nov-87 1745 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
C03200 00605 ∂25-Nov-87 1750 CL-Cleanup-mailer Issue status
C03222 00606 ∂27-Nov-87 0751 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 5)
C03225 ENDMK
C⊗;
∂23-Apr-87 1359 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue DEFVAR-INIT-TIME (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 13:59:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123216; Thu 23-Apr-87 16:59:34 EDT
Date: Thu, 23 Apr 87 16:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DEFVAR-INIT-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating
the form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE
form is not evaluated unless it is used; this fact is useful if
evaluation of the INITIAL-VALUE form does something expensive like
create a large data structure.''
Although I think the original CL designers all knew what this wording
was intended to mean, I have discovered people who have misinterpreted
the "unless it is used" to mean "unless the variable is used" rather
than "unless the initial-value is to be used". The problem is that the
"it" is ambiguous.
Having made this false assumption, the people I talked to thought --
and understandably (if lamentably) so -- that they wouldn't know if
the variable was to be used until the code ran, so they had the model
that the intention was to provide a kind of lazy initialization that
happened upon the variable's first unbound reference. This confusion
appears to have been further supported by the additional verbiage about
not creating expensive structures that are not needed.
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all).
Rationale:
I think it was clear at design time that this was intended. The manual
should therefore be clear.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
The misinterpretation is much harder to implement than the proposed
interpretation. Adoption of the changes should be straightforward.
Benefits:
This clarification makes the semantics of an important primitive
more well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
KMP thinks this clarification is important.
∂23-Apr-87 1432 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:32:25 PDT
Received: from johannes-scotus-erigena by Think.COM via CHAOS; Thu, 23 Apr 87 16:36:10 EST
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
--Guy
∂23-Apr-87 1447 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:47:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123309; Thu 23-Apr-87 17:46:56 EDT
Date: Thu, 23 Apr 87 17:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: GC-MESSAGES
References: None
Category: ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Although there is no standard interface to the garbage collector,
it is common for there to be a garbage collector in nearly every system.
In many systems, these do unsolicited typeout which obstructs program
typeout in unpredictable ways.
Proposal (GC-MESSAGES:FLAG-VARIABLE):
Make a variable called *GC-MESSAGES* which controls GC message typeout.
Possible values of this stream include:
T Standard notifications (typically to *TERMINAL-IO*).
NIL No notifications.
Since not all implementations could allow an arbitrary user-supplied
stream for use as a value of *GC-MESSAGES* (because streams might cons
and consing might be illegal at the time of the message), this cannot
be offered as an option. However, this would be a reasonable
implementation-dependent extension in some systems, so we should offer
it as an option.
In multi-processed, shared-address space implementations, if the GC is
going to type a message on a stream that belongs to some other process
(or otherwise ``notify'' the process, to use Lisp Machine terminology),
the value of *GC-MESSAGES* in the process being notified should be used
rather than the value in the current process so that this variable can
be usefully bound by user programs.
Permit that as an act of desperation, shortly before running completely
out of space when *GC-MESSAGES* is NIL, the GC may notify the user
that he is about to lose (in spite of the fact that he has seemingly
asked to lose). This permission is important so that people don't feel
afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages
only for fear that they might not get critical last minute information
that says it's time to do drastic cleanup action.
Rationale:
Application programs which do display (especially display which conses)
need a way of deferring GC warnings that might ruin the display.
Current Practice:
This functionality is provided in some form or another by a number of
implementations.
Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
or a stream. It provides useful flexibility and is used by quite a number
of users.
Other systems provide ways of enabling or disabling the messages, or of
customizing the message which is typed out.
Adoption Cost:
The set of places in which the GC does typeout is probably very
restricted, so finding them and changing them to be appropriately
conditionalized is probably not a lot of work.
Benefits:
This would allow the user some portable control over a common feature which
cannot currently be controlled in a portable way.
Conversion Cost:
This is an upward compatible change.
Aesthetics:
No significant impact.
Discussion:
MACSYMA needs this (so it can bind it to NIL). Its display often does
consing. In some implementations this can cause a GC, which can in turn
spoil the carefully crafted display.
∂23-Apr-87 1453 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:53:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123312; Thu 23-Apr-87 17:50:35 EDT
Date: Thu, 23 Apr 87 17:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: Guy Steele <gls@Think.COM>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Message-ID: <870423175014.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
row-major-aref or aref-row-major would be good names. I think
KMP's suggested function is sufficiently specialized that it does
not need an especially short name.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
array-row-major-index is already in the language.
∂23-Apr-87 2031 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:31:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123639; Thu 23-Apr-87 23:31:18 EDT
Date: Thu, 23 Apr 87 23:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423233110.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This seems a little short-sighted. GC messages aren't necessarily the
only unsolicited messages. In the example application you gave, there
is no reason to treat GC messages differently from other messages.
Also, a simple on/off switch may be a bit too simple. Not all systems
have windows, but for the ones that do a three-state switch could be
defined in an implementation-independent way: (1) turn the messages off,
(2) put them in the typescript, (3) make them visible to the user in a
way that doesn't interfere with the typescript. Even some
teletype-oriented systems are able to implement option 3.
In some systems it may not be possible to implement this with a variable,
since changing the state of the switch may have to communicate with an
operating system written in some horrible language. The safest thing would
be a macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.
I'm not very optimistic about the possibility of standardizing on this kind
of environmental issue, but perhaps some very simple facility to prevent
messing up of the screen can be agreed on.
∂23-Apr-87 2150 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:50:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123691; Fri 24-Apr-87 00:49:23 EDT
Date: Fri, 24 Apr 87 00:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@sail.stanford.edu
cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
In-Reply-To: <870423123259.1.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <870424004910.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's an opinion on this issue from one of our developers, with an
interesting rationale. I agree with the rationale, which is why I
support either the mentioned proposal or the one that signals an error
and allows the outer THROW to be completed from the debugger.
Date: Thu, 23 Apr 87 12:32 EDT
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
I found KMP's proposal for this and I can now comment effectively. My
personal feelings are that the right proposal for 1 is the one below. I
agree with KMP that 2C is correct for 2.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1?):
Some may believe that the throw to BAR is suppressed,
the THROW to FOO should somehow complete, but that XXX would
never be printed.
The important factor here is that I believe that whenever there are two
THROW's in competition, that we should always proceed to the outermost
CATCH. This rule permits a programmer to assume that if he does a THROW
out of a computation that that computation will be exited, one way or
another. This is related to Moon's comment about the programming
environment and aborting.
∂23-Apr-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:57:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123694; Fri 24-Apr-87 00:57:35 EDT
Date: Fri, 24 Apr 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870424005727.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The wording of your proposal is such that it implies that implementations
that ignore the :ADJUSTABLE argument and simply make all arrays adjustable
would no longer be valid. I doubt that you intended this. Implementations
should not be required to implement the non-adjustability complexity if
they don't need it.
Your comment about dead arrays is too obscure.
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
∂23-Apr-87 2209 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:09:05 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 21:08:20 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA25436; Thu, 23 Apr 87 20:39:17 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA06857; Thu, 23 Apr 87 21:36:52 PDT
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240436.AA06857@bhopal.edsel.com>
To: navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu
In-Reply-To: Guy Steele's message of Thu, 23 Apr 87 17:33 EDT
Subject: AREF-1D
Your "clarifications" of 6-Dec-85 (distributed at the Boston Meeting
of what eventually became X3J13) added a function named ROW-MAJOR-AREF.
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
-- JonL --
∂23-Apr-87 2255 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:52:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123714; Fri 24-Apr-87 01:52:42 EDT
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-ID: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The reason for the name clash is that I wasn't looking at Steele's
corrections list at the time I generated the proposal. It was on an
independent list of Macsyma-related issues of my own. Sorry for the
confusion.
The fact that the row-major feature is built into more functions than
just those which have the phrase "ROW-MAJOR" in them (eg, displaced
arrays) leads me to believe that the phrase ROW-MAJOR is just redundant.
Also, I don't like the phrase "ROW-MAJOR" because it feels very 2d
because the term row seems to apply to 2d matrices. I know it's got a
perfectly well-defined way of generalizing, but...
Also, I thought a name with "1D" in it would emphasize that this was
a non-standard access. I guess "ROW-MAJOR" does that, too, though.
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
∂24-Apr-87 1326 masinter.PA@Xerox.COM Re: Issue DEFVAR-INIT-TIME (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 13:26:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 APR 87 13:17:43 PDT
From: masinter.PA@Xerox.COM
Date: 24 Apr 87 13:17:31 PDT
Subject: Re: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 23 Apr
87 16:59 EDT, <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870424-131743-2546@Xerox>
Kent,
Perhaps you could hold off submitting more issues until we get some of
the open ones out of the way?
∂24-Apr-87 1846 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 18:46:54 PDT
Received: by navajo.stanford.edu; Fri, 24 Apr 87 17:46:11 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA29466; Fri, 24 Apr 87 17:09:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA07893; Fri, 24 Apr 87 18:07:26 PDT
Date: Fri, 24 Apr 87 18:07:26 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704250107.AA07893@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 24 Apr 87 00:57 EDT
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
The complexity of this discussion about adjust-array makes me wonder
if this function isn't striving for too much generality. Virtually all
usages I've seen or heard of are really for adjust-array-size. KMP's
proposal sounds like he's trying to avoid simply makeing a new array and
copying (after some fashion) the old into the new. Maybe it's a simpler
language design not to try to cover every possible base, but to provide the
primitives that permit end-users to "roll their own". In line with
your remarks:
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
How about the following simplification for adjust-array:
(1) a new function shall be added which will copy parts of the contents
of one array into another; MacLisp's FILLARRAY is a base-level start
for such a function, but one would like something for multi-dimensional
arrays that is more meaningful than simple linear, row-wise fill.
(2) adjust array will only "mess" with the size (or dimensions) and with
the displacement (i.e., to a new target array, or new index-offset).
Fill-pointers can already be modified with setf. Getting new contents
into a displaced, "adjusted" array can be done by first calling the
function ARRAY-DISPLACED-P (as specified in GLS's "clarifications" of
6-Dec-85) and then using the function called for in (1) to copy parts
of the original displaced-to array into the newly-displaced one.
-- JonL --
∂25-Apr-87 0021 gls@think.com DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Apr 87 00:21:31 PDT
Received: by Think.COM; Sat, 25 Apr 87 02:25:34 EST
Date: Sat, 25 Apr 87 02:25:34 EST
From: Guy Steele <gls@think.com>
Message-Id: <8704250725.AA21198@Think.COM>
To: cl-cleanup@sail.stanford.edu
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
Here is an idea that is only two-thirds whimsical: since 90% of all
people who use DELETE, SORT, etc. lose because they fail to put a setq
around it (as in (SETQ X (DELETE ITEM X)), etc.), why not make it
impossible for them to lose? Remove these primitives from the language,
and introduce their inverses as SETF places. For example, instead of
writing (SORT BREAKFAST) or (SETF X (SORT BREAKFAST)), write
(SETF (SCRAMBLE X) BREAKFAST)
; that is, the variable X is changed so as to make the value of
BREAKFAST a scrambled version of it. SCRAMBLE would not be a function
itself; you could use it only within a SETF, thereby guaranteeing you
don't lose. Similarly (SETF (UNDELETE ITEM Z) Z),
(SETF (UNADJUST-ARRAY Z) Z), and so on.
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
--Yours for a safer language,
Quux
P.S. I thought you'd never ask: haven't you ever had
scrambled X for breakfast?
∂27-Apr-87 1151 Masinter.pa@Xerox.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:51:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 11:43:07 PDT
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 23 Apr 87 17:50 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870427-114307-1095@Xerox>
How does this (new) proposal relate to the (old) proposal by Touretsky?
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
∂27-Apr-87 1312 Masinter.pa@Xerox.COM status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:12:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 13:07:08 PDT
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870427-130708-1239@Xerox>
This is my status file. Please mail any corrections you have.
I don't think we've made very good progress. The only issue that I've
seen resolution on since our meeting before X3J13 is
FLET-IMPLICIT-BLOCK.
I think we can re-release COMPILER-WARNING-STREAM ( Version 3),
DEFVAR-INITIALIZATION (Version 3), FORMAT-ATSIGN-COLON (Revision 3),
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, DO-SYMBOLS-DUPLICATES (Revision 1),
GET-SETF-METHOD-ENVIRONMENT, FORMAT-OP-C (revision 1), FUNCTION-TYPE
(revision 2), IF-BODY (Version 4), KEYWORD-ARGUMENT-NAME-PACKAGE
(Version 1), PRINC-CHARACTER:WRITE-CHAR
The rest seem further from general agreement of the form of the
proposal.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ADJUST-ARRAY-NOT-ADJUSTABLE
Submitted by KMP 22-Apr-87
comment from Moon, JonL 24-Apr
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Revision 1 by SEF, 18-Apr-87
Comment by Moon 21 Apr 87
AREF-1D
Submitted 22-Apr-87 by KMP
Discussion about name of function, addition of ROW-MAJOR-INDEX
function, etc.
ROW-MAJOR-AREF in clarifications
ASSOC-RASSOC-IF-KEY
Submitted 22-Apr-87 by KMP
COMPILER-WARNING-BREAK (revision 2)
not Released.
Questions on interaction with condition proposal.
remailed 7-apr-87
SEF suggested KMP should work on.
COMPILER-WARNING-STREAM (Revision 4)
Rev 3 was released
Version 4, submittted by SEF
Decided to revert to previous version,
consider DRIBBLE as a separate item.
Need to add DRIBBLE note in Discussion.
DEFVAR-INITIALIZATION (Revision 3)
Released
remailed 7-apr-87
(final form)
DEFVAR-INIT-TIME
Submitted 23-Apr-87, Version 1 by Pitman
DO-SYMBOLS-DUPLICATES (Revision 1)
mailed 7-apr-87
Revision 1 by SEF 17-apr
Not released, in discussion
Questions "is it really inefficient to require non-duplicates?" Add
more arguments?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF summarized issues 18-Apr
Decided to separate again and:
Approve GET-SETF-METHOD-ENVIRONMENT
drop MACRO-FUNCTION-ENVIRONMENT
("merely adding an optional argument to macro-function is not
enough")
discuss SPECIAL-FORM-SHADOW
FLET-IMPLICIT-BLOCK (Revision 5)
Discussion & agreement on cl-cleanup.
revision by Fahlman, 17-Apr-87 to cl-cleanup
FORMAT-ATSIGN-COLON (Revision 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Mailed 17-Apr-87
Fahlman volunteered to revise & run by RPG
GC-MESSAGES (version 1)
Submitted by Pitman 23-Apr-87
Discussion "a little short-sighted"?
IF-BODY (Version 4)
General agreement to recommend against.
Final form not yet available.
Version 4 mailed by KMP , 19-Apr-87
KMP to produce a new version which Scott will think is balanced
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
Submitted by Moon 20 Apr 87.
Discussion: justification with examples or reference needed before
releasing to X3J13
"I'm sure you've got a good reason for proposing this,
and I'd like some indication of what it is."
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed at meeting, final form not yet available
Moon forwards Hornig msg pointing some problems 23-Apr-87
∂28-Apr-87 1114 KMP@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 11:13:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126277; Tue 28-Apr-87 14:13:26 EDT
Date: Tue, 28 Apr 87 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <12276526020.28.TOURETZKY@C.CS.CMU.EDU>,
<870315-164404-1975@Xerox>
Message-ID: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
Status: For Internal Discussion
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Notes about Voting:
Select one of:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED (by Pitman)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED (status quo)
[See also notes in the discussion about the possibility of a fourth
way to go if you're not satisfied with any of these.]
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on arbitrary arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Modify the definition of MAKE-SEQUENCE to accept array descriptions as
well as vector descriptions.
Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays.
These functions should treat array arguments as vectors displaced to the
array storage (in row-major format). The affected functions are LENGTH,
ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE, NREVERSE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
and (ELT A 7) should return A[0,1,0]. :START and :END keywords would
be interpreted relative to the vector, as would the results returned
by POSITION and SEARCH.
Extend the definitions of sequence functions whose result should be the
same shape as but not necessarily EQ to some argument. These functions
should deal with array arguments by returning an array of the same
shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.
Expressly forbid arrays as arguments to sequence functions that modify
the number of elements in the array because the shape would be undefined.
These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE,
REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a
sequence function, and it already has a well-defined behavior for arrays.
To test whether the arrays A and B, of different shapes, have the same
elements, one would write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, REDUCE, etc., or else they can build displaced vectors by
hand and pass them to the sequence functions when necessary.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and
the SETF expander for ELT would have the side effect of extending
the remaining functions if they are written in the obvious way.
For example:
(DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
(LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
(DOTIMES (I (LENGTH SEQUENCE) RESULT)
(SETF (ELT RESULT I)
(IF (EQL (ELT SEQUENCE I) OLD-ITEM)
NEW-ITEM
(ELT SEQUENCE I))))))
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly
avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives
(which would be needed to take arbitrary k-dimensional slices out of
n-dimensional arrays, or to apply an operator across a specific
dimension of a multidimensional array), it requires just one rule:
treat arrays as displaced vectors.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions. These
unaffected functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED):
This is the null proposal for the sake of voting clarity. Vote for this
if you think things should not change.
Current Practice:
Neither SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE nor
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED are likely to be implemented
anywhere since they are only very recently proposed.
Discussion:
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE.
He's been building displaced vectors to pass to sequence functions when
necessary and really dislikes it.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited.
Rees suggested that if people are not sure about this a proposal, it might
be possible to make fly a modified version of the proposal which extended
only those functions which did not deal with positional information.
Pitman wrote SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED based on this idea
and supports at least that much extension, and is sympathetic to (but not
yet fully committed to the idea of the full proposal).
Note that in the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED proposal,
the function REDUCE is in a grey area. Many of its uses are not
position-dependent, but some are. The same argument might be made about
FIND. If people felt strongly, these too could be extended either by
fudging the conservative rule or by explicit special case(s).
[It's also possible that a still-more-general proposal might be
interesting. For example, one that introduced and inverse to
ARRAY-ROW-MAJOR-INDEX called ARROW-ROW-MAJOR-SUBSCRIPTS, and have
functions like POSITION that returned position information or things
that take :START and :END arguments use subscript (rather than offset)
information. eg,
(SETQ A (MAKE-ARRAY '(2 2) :INITIAL-ELEMENT 0))
(SETF (AREF A 1 0) '1)
(POSITION 1 A) => (1 0) ;Rather than 2 as suggested above
This might ease some people's minds if they're just worried that
returning a 1-d index will feel funny for an any-d array. On the
other hand, the linear ordering must still be well defined so it'll
be clear what the search order is, what range is being selected when
:START and/or :END is used, etc. so you can't hide the issue
completely. Still, if anyone's interested in a full-blown proposal
along these lines, they should ask me and I'll write it. --KMP]
∂28-Apr-87 1334 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87 13:34:01 PDT
Date: Tue, 28 Apr 87 16:35:56 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU
Message-ID: <192342.870428.JAR@AI.AI.MIT.EDU>
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ENHANCEMENT
Edit history: Revision 2 by JAR 04/28/87
Status: Very preliminary.
Description of problem:
CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
declared special, then a free reference to that name is a reference to
the special variable of that name, while a LAMBDA-binding of that name
indicates a binding of the lexical variable of that name. This would
mean that the following program is legal and that (TST) => 4:
(defun tst ()
(setq x 3)
(funcall (let ((x 4)) #'(lambda () x))))
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
This disagreement between theory and practice should be mended
somehow.
Proposal (PROCLAIM-LEXICAL:CURRENT-PRACTICE):
Change the language definition (page 55?) to say that it is an error
for there to be a free reference or assignment to a name unless a
SPECIAL proclamation or declaration is in effect for that name.
This would legitimize the behavior of current implementations.
Proposal (PROCLAIM-LEXICAL:BY-THE-BOOK):
Shame implementors into going by the book. Implementations should
simply stop intimidating users who want to write code like this.
"Apparently unbound variable" warnings should be given the same
purely advisory status that "apparently undefined function" warnings
now enjoy. The exact meaning of this is of course implementation-
dependent.
Proposal (PROCLAIM-LEXICAL:GENERAL):
Introduce a new declaration specifier, LEXICAL, which is dual to the
SPECIAL declaration specifier; it may appear in proclamations and
declarations.
A name may be proclaimed either lexical or special, but not both.
A free reference or assignment to a name is an error if there is
neither a SPECIAL nor a LEXICAL proclamation or declaration in
effect for the name. A LAMBDA-binding in the absence of a
declaration or proclamation binds the lexical variable.
The global lexical environment and the global dynamic environment
are identical. I.e. an assignment to the global binding of a
lexical variable will be reflected in the observed global value of
the dynamic variable of the same name, and vice versa.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
Proposal (PROCLAIM-LEXICAL:RESTRICTED):
Same as PROCLAIM-LEXICAL:GENERAL, but with the following restriction:
If a name is proclaimed lexical, then it is an error for there to be
a special declaration of the same name. For example, the special
declaration of X in the example is an error.
Cost of adopting change:
CURRENT-PRACTICE: Ostensibly none, although implementations which
don't signal this as an error should be explicitly encouraged
to do so. It ought to be signalled in interpreted code as well.
BY-THE-BOOK: This would be an easy fix to the error reporting and
bookkeepping components of existing compilers. Of course it is not
a change to the language, so there is no impact on portable code.
GENERAL: This would be straightforward to implement, and is perhaps even
already present, in implementations that use deep binding for
special variables. In shallow bound implementations there's a
problem because two "global" value cells are needed: one for the
current dynamic binding, and one for the global lexical binding;
and when no dynamic binding is in effect, they must somehow be
"coalesced" so that SETQ's are reflected in both.
RESTRICTED: This is specifically designed to address the
implementation problems of GENERAL. Having a dynamic binding and
having a global lexical binding are mutually exclusive.
Benefits:
CURRENT-PRACTICE is incompatible with Scheme, which explicitly
allows a program to have both a global binding and LAMBDA bindings
of the same variable. Therefore, adopting any of the other three
proposals would be a major step towards reducing the
incompatibilities between the two languages, since both code
conversion and embedded scheme implementations would be made easier
and more graceful.
GENERAL and RESTRICTED have the additional advantage that, in an
implementation that uses deep binding for dynamic variables, a
lexical proclamation can be used to achieve significant performance
gains on references and assignments to global variables. A LEXICAL
proclamation would also allow some desirable redundancy, both
for documentation and for error checking.
Cost of converting existing code:
CURRENT-PRACTICE: Some programs may rely on the CLtL semantics;
these would have to be changed if what they're doing now becomes
officially erroneous. People might find consistent enforcement
of this rule rather surprising and frustrating.
GENERAL and RESTRICTED are both upwards compatible. Of course,
code-walking utilities would have to be taught about the new
feature, since it affects the basic semantics of the language.
Aesthetics:
The special/lexical business is generally one of CL's most insidious
and disgusting aspects, and really needs a much more thorough
overhaul than is proposed above (e.g. there ought to be a separate
DYNAMIC-LET or SPECIAL-LET which does dynamic binding). But this is
probably practically and politically infeasible. Given that, I
don't think any of these proposals has clear advantages or
disadvantages from the point of view of simplicity or elegance of
description, except that GENERAL is somewhat easier to describe
than RESTRICTED.
Discussion:
The four proposals indicate the range of possibilities. After some
discussion, we ought to be able to prune this down, of course.
JAR thinks that CURRENT-PRACTICE is unacceptable, BY-THE-BOOK is
unsatisfying but somewhat better, and GENERAL has unsolved implementation
problems, even though it seems the most powerful, symmetric, and elegant.
Thus RESTRICTED seems preferable.
This proposal ignores the question of what to do about an analogue
of DEFVAR or DEFPARAMETER for global lexicals. Interlisp and PSL both
have something along these lines (DEFGLOBAL), don't they?
Given the presence of lexical proclamations in the language, it's
still not clear whether a free, undeclared, unproclaimed reference
should be an error, and if it's not an error, whether it should refer
to the lexical binding or the special binding. I suggest that it not
be an error, and I don't really care what its meaning should be (since
in the situation I care about I'm not going to be dynamically binding
the variable anyhow, so it doesn't matter). The RESTRICTED semantics
would imply that such a reference would have to be to the special
variable.
[By the way, I don't like this use of the term "variable," but I'm
trying to be consistent with CLtL p. 55. Note that according to this
it doesn't make any sense to talk about "declaring a variable to be
special" since any variable is already either special or lexical; it
is names which can be so declared. The book is definitely NOT
consistent about this, and ought to be fixed.]
∂28-Apr-87 1916 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 19:16:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126601; Tue 28-Apr-87 18:52:26 EDT
Date: Tue, 28 Apr 87 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, JAR@AI.AI.MIT.EDU
Message-ID: <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support PROCLAIM-LEXICAL:GENERAL if the implementation issues can
be worked out, which I think they can.
I spoke with Jonathan briefly about these problems and I think he
agrees with me that they're not really a problem if you just keep
the global lexical value cells someplace other than the SYMBOL-VALUE
of the symbol.
For example, you might write:
(DEFVAR SYSTEM:*THE-GLOBAL-LEXICAL-VALUE-CELLS* (MAKE-HASH-TABLE))
(DEFUN SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (SYMBOL)
(OR (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(SETF (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(CONS SYMBOL ;For debugging
SYSTEM:*UNBOUND-MARKER*))))
(DEFMACRO SYSTEM:GLOBAL-LEXICAL-VALUE (SYMBOL)
`(CDR (EVALUATE-AT-LOAD-TIME (SYSTEM:GLOBAL-LEXICAL-VALUE-CELL ',SYMBOL))))
Of course (as stated above), this changes his proposal slightly to
make the global lexical and dynamic environments disjoint. That is,
programs like
(DEFUN MAYBE-EVEN-BUT-SURELY-ODD ()
(+ (LOCALLY (DECLARE (LEXICAL X) (INTEGER X)) X)
(LOCALLY (DECLARE (SPECIAL X) (INTEGER X)) X)))
could return odd numbers (since lexical X and special X might denote
different quantities).
The contract of the compiler would be to turn global lexical
references to a symbol into (SYSTEM:GLOBAL-LEXICAL-VALUE 'symbol).
The call to SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (ie, the GETHASH) need
happen only once (at load time) so its speed is not important.
If the above code wanted to be portable, of course, you'd have to have
an S-expression equivalent to #, called EVALUATE-AT-LOAD-TIME. Most
implementations have such a thing, I think, they just don't let it out
for users to play with. In fact, I think CL should have such a thing
since this isn't the first case where people have wanted it.
In any case, portability isn't relevant to this message since all
that's needed is to demonstrate that it would be feasible to implement
this in all systems, which I think the above code demonstrates.
∂28-Apr-87 2204 masinter.PA@Xerox.COM Re: Issue: PROCLAIM-LEXICAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 22:04:03 PDT
From: masinter.PA@Xerox.COM
Date: 28 Apr 87 22:02:51 PDT
Subject: Re: Issue: PROCLAIM-LEXICAL
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Tue, 28 Apr
87 18:52 EDT, <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Message-ID: <870428-220403-2039@Xerox>
Jonathan left out the alternative that I thought most natural, namely
that otherwise undeclared
variables were not an error, but would default lexical. E.g.,
(setq x 3)
(defun frob () (incf x))
would not be an error, but would always refer to the lexically global x.
This would bring variable scoping in line with function scoping when
there were no declarations. (A state of grace.)
I presume that Kent didn't really mean to propose that the global
lexical environment be different from the global dynamic environment,
but that was just an awkward artifact of his sample implementation.
Right Kent?
The only idiom which might have portability problems are dynamic calls
to EVAL that get the dynamic binding, e.g., instead of using
SYMBOL-VALUE, e.g., user has a data base of permutations of variables &
values, and also of expressions, binds the variables with PROGV and then
evaluates the expressions.
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
∂29-Apr-87 0641 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 06:35:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126932; Wed 29-Apr-87 09:35:59 EDT
Date: Wed, 29 Apr 87 09:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PROCLAIM-LEXICAL
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
JAR@AI.AI.MIT.EDU
In-Reply-To: <870428-220403-2039@Xerox>
Message-ID: <870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sympathetic to the idea that undeclared free variables should
default lexical. Certainly if we had lexical globals I'd expect that
some compilers would start defaulting free variables lexical while
others would continue to default them special, so perhaps we should
just go ahead and make it well-defined.
Anyway, the separation of global lexical environment from global special
environment seems to me important. After all, you can already do:
(DEFUN F (X) (+ X (LOCALLY (DECLARE (SPECIAL X)) X)))
and see two different variables X without any intervening rebinding.
I was just assuring that this effect was properly carried through.
Also, this assures that people cannot muck with the lexical binding
of any variable. Special variables are kind of 3lispy in nature because
we're told how they're represented and we have primitives for manipulating
them either as variables or as data. I think this makes program proofs
more difficult. The feature of lexical variables is that all of their
uses are statically detectable; this would not be so for global lexicals
if their homes were something that users were permitted to read in a
non-statically-detectable way (eg, using SYMBOL-VALUE) or set (using SETF
of same). By making the lexical bindings totally isolated, you ensure
the right of the compiler to do much better compilation of global lexicals
in some cases than it might be able to do for global specials, and at the
same time you don't make any unpleasant changes to the mechanisms already
in place and in use for specials.
And finally, if you separate the two spaces, then you can go back and
forth between declaring variables special or not without it having strange
effect on things already compiled. eg, if you needed:
(DEFGLOBAL Y 3)
(DEFUN F (X) (+ X Y))
...
(PROCLAIM '(SPECIAL Y))
(DEFUN FOO (Y) (BAR))
(DEFUN BAR () ... (SETQ Y ...) ...)
(PROCLAIM '(LEXICAL Y))
without worrying that the global lexical Y=3 binding was in danger
of getting modified (which it seems intuitive to me that it should
not have been).
MACSYMA, for example, needs an UNSPECIAL declaration because on a
per-file basis it goes back and forth between using the same name either
special or lexical. Alternating back and forth between default LEXICAL
and default SPECIAL would serve it as well if we made that legal.
If such alternation meant that programs previously compiled using the
other semantics were now in error or might behave differently than I
intended at time-of-definition, then you've defeated the purpose of my
doing the alternation. I think the separation of namespaces ensures
intuitive behavior.
∂29-Apr-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:38:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127175; Wed 29-Apr-87 12:38:42 EDT
Date: Wed, 29 Apr 87 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and
~:C equivalently or very similarly, which seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice (unless you use
~Q of #'WRITE-CHAR -- which is generally neither pretty nor convenient).
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Add the following to the description of WRITE-CHAR on p384:
Note: The glyphs used to present characters which are not in
the standard character set may vary from implementation to
implementation or output device to output device. WRITE-CHAR
will always output a single character to the indicated stream.
On some streams, super-quoting, character substitution, or
substitution of a string for a single character may be
necessary; it is appropriate for the stream to decide to do
this, but WRITE-CHAR itself will never do this.
Rationale:
This was probably the intent of the authors.
It makes things clear enough that programmers can know what to
expect in the normal case (standard characters with zero bits)
while leaving some flexibility to implementors about what to do in
the case of bits (which are not particularly well-defined across
different implementations anyway).
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
Pitman thinks it's important to get this cleared up as soon as possible.
Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
identical in all cases) was:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
Steele and Fahlman seemed to like the idea of the proposal if amended
as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
blow it somehow, they should now be happy.
∂29-Apr-87 0943 KMP@STONY-BROOK.SCRC.Symbolics.COM status of DEFVAR-INIT-TIME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:43:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127180; Wed 29-Apr-87 12:43:47 EDT
Date: Wed, 29 Apr 87 12:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: status of DEFVAR-INIT-TIME
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <870427-130708-1239@Xerox>
Message-ID: <870429124341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
This is my status file. Please mail any corrections you have.
...
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, ...
I saw no reply at all to DEFVAR-INIT-TIME (other than your mail saying
to please hold off on new proposals until the ones we have get cleaned up).
In the absence of any comments on what might be wrong with this proposal
(which I personally think is pretty non-controversial), I'm not able to
produce an update. If anyone has objections (or just wants to second it
as-is), they should voice them.
∂29-Apr-87 1024 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:24:34 PDT
Date: Wed, 29 Apr 87 13:26:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: masinter.PA@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of 28 Apr 87 22:02:51 PDT from masinter.PA at Xerox.COM
Message-ID: <192793.870429.JAR@AI.AI.MIT.EDU>
Date: 28 Apr 87 22:02:51 PDT
From: masinter.PA at Xerox.COM
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
The VAX LISP interpreter will generate such warnings if an internal,
unreleased switch is set non-nil. Its default value is nil. For a week
or two when the feature first appeared (only inside DEC, of course) the
switch was defaultly true. Some people liked the immediate feedback,
but overall the warnings were judged too radical and disconcerting, so
the default was changed.
∂29-Apr-87 1025 KMP@STONY-BROOK.SCRC.Symbolics.COM Procedure for Steele's proposed clarifications
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:25:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127203; Wed 29-Apr-87 13:08:07 EDT
Date: Wed, 29 Apr 87 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Procedure for Steele's proposed clarifications
To: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <870427-130708-1239@Xerox>
Message-ID: <870429130801.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
If something is in Steele's clarifications (X3J13/86-003), do we
still need to write it up in full blown form for vote?
In particular, does the fact that my AREF-1D proposal overlaps
with the proposal for ROW-MAJOR-AREF mean that I should modify
my proposal to use the new name (which I'm certainly content to
do) or that I should retract my proposal since the same proposal
is already on the floor.
I certainly think that full-blown forms of all the things in
the clarifications would be nice because it would save a lot of
time at meetings answering obvious questions, but some of the
things in that document are pretty simple and straightforward
in their one-liner form and I just want to clarify before doing
a lot of work that expanding them is what is intended.
∂29-Apr-87 1131 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 11:30:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127310; Wed 29-Apr-87 14:18:24 EDT
Date: Wed, 29 Apr 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
In-Reply-To: <870427-114307-1095@Xerox>
Message-ID: <870429141817.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
How does this (new) proposal relate to the (old) proposal by Touretsky?
[For Touretzky's context, the "new" proposal being referred to was one to
introduce a function AREF-1D (later renamed to ROW-MAJOR-AREF to correspond
to a name chosen earlier by Steele in a suggested clarifications document
he distributed).]
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
At first I wondered if the omission of a proposal to generalize AREF so
that if you gave it a single index it (implicitly asserting it to be a
vector, and hence a sequence), then it should just do a 1-d AREF (as ELT
would do). In fact, however, I think this would decrease error checking
in an undesirable way and my guess is that Touretzky was being very
deliberate in not including a proposal to do this.
Moreover, although some compilers might treat
(ELT (THE ARRAY X) 3)
as efficiently as
(ROW-MAJOR-AREF X 3)
I don't think anyone would be willing to require such efficient treatment.
In compilers which didn't optimize this (and in most interpreters, too)
you'd still have to do the LISTP check before getting around to the
implicit ROW-MAJOR-AREF. Although it isn't suggested that ROW-MAJOR-AREF
is needed only for efficiency, it is true that most applications where it's
likely to be used need maximal efficiency, so I think making it a separate
primitive is appropriate.
All this being said, I think it's safe to make these two proposals proceed
in parallel without worrying that they conflict in some way. If you're not
convinced, please let me know.
∂29-Apr-87 1234 Pavel.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 11:53:00 PDT
Date: 29 Apr 87 11:52 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-115300-2626@Xerox>
The mention of the non-standard format directive ~Q should be removed
from the proposal. Other than that, I favor it.
Pavel
∂29-Apr-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:46:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127412; Wed 29-Apr-87 15:46:19 EDT
Date: Wed, 29 Apr 87 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I removed the FORMAT-OP-C proposal from this since no one seemed to be
championing it. As far as I know, this was the only simplification anyone
had asked for. -kmp
========================================================================
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
KMP thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1337 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 13:37:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127499; Wed 29-Apr-87 16:37:14 EDT
Date: Wed, 29 Apr 87 16:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870427182129.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
Message-ID: <870429163704.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I hope this draft manages to merge the IF-BODY:NO stuff in
a relatively fair way. -kmp
``... looks reasonably balanced to me, and represents my
own opinions adequately. I see no objection to releasing
it to the world at large ...''
-- Guy L. Steele, Jr.
author of ``Common Lisp: The Language''
==============================================================================
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (added IF-BODY:NO)
17-Apr-87, Version 3 by Masinter (merged v1 and v2)
19-Apr-87, Version 4 by Pitman (misc editing to v3)
27-Apr-87, Version 5 by Pitman (reworked for balance)
Status: Not for release
Problem Description:
CLtL defines the meaning of an IF expression only in the case of two or
three arguments. Some implementations extend the meaning to allow more
arguments.
Typically, using the extended IF syntax will not generate a warning in
environments which support it. Code developed where these features are
available is not typically discovered to be in error until a port to
some other implementation is attempted. At that point, which is
typically inconveniently late in the development cycle, the developer
may notice that code either does not compile (generates syntax errors)
or does not compile correctly (the additional forms are quietly ignored
and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
This phenomenon is a barrier to Common Lisp's portability goals.
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
According to CLtL, this is an error.
In some implementations, this returns ELSE.
In some implementations, this returns MORE.
In some implementations, this signals an error at syntax analysis time.
Notes about Voting:
Select one of IF-BODY:ILLEGAL, IF-BODY:LEGAL, or IF-BODY:UNCHANGED.
Proposal (IF-BODY:ILLEGAL):
Restrict IF, making it expressly illegal to supply more than three
argument forms. Require that implementations signal an error at
syntax analysis time.
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
The direct act of making this restriction is trivial, but there
are nth order effects which may be non-trivial...
In Symbolics implementations the SCL package contains Symbolics'
extensions to LISP. Currently, for any symbol LISP:xxx, the
expression (EQ 'LISP:xxx 'SCL:xxx) => T. This change would force
as a second order effect a decision about whether to make
(EQ 'LISP:IF 'SCL:IF) => NIL or to rewrite all code (user and
system) using the extended IF.
Since there are currently no cases where LISP symbols are not
shared by SCL, a decision to break the sharing would force us
to do a complicated re-evaluate our position on the nature of
compatibility between Common Lisp and the extensions we provide.
The cost of this option is therefore potentially large.
Conversion Cost:
Uses of IF in correct Common Lisp code are technically unaffected
by this change, although it should be clear from the discussion
of Adoption Cost that viewing things this way may be just a word
game. In practice, there might be non-trivial effects on
code that is not technically `Common Lisp' but which is thought to
be `Common Lisp compatible.' The importance of this must be weighed
in context, but should not be discounted altogether.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
In most implementations, making this syntax legal is a matter of
a fairly localized change to a finite number of utilities which
reason about programs (compiler, interpreter, code walkers). No
changes to code which does not reason about programs would be
necessary.
In some implementations which have incompatible extension
strategies, such as keyword-driven facilities, the cost is higher
because this is an incompatible change. The cost of adoption in
such cases is hard to estimate; implementors who feel they have
severe concerns about this should raise those concerns and we'll
modify this proposal to reflect them.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The resolution of this controversial programming style issue
is left to the user rather than being forced by the language
designer. Those who prefer the symmetry of the (IF test then else)
syntax are free to use it exclusively without infringing on the
desires of others to use the extended syntax.
Some people find the alternatives to (IF test then {else}*) to
be too visually cumbersome.
Although IF was supposed to be a simple conditional form, usage
patterns suggest that this is not uppermost in many users' minds.
Experience in user communities where extended IF is available
show that few users object to its presence; most are happy for
the syntactic flexibility it provides.
Proposal (IF-BODY:UNCHANGED):
Leave IF as currently specified in CLtL.
Implicit in this proposal is that it would be valid for any
implementation to extend IF as long as such an extension was done
in a way that was `upward compatible' with Common Lisp.
Rationale:
The other two proposals are inadequately motivated.
Since some implementations already support extensions, it would
be disruptive to those implementations to require that the
extensions be removed. Not altering the current definition is
maximally conservative with regard to existing code.
Adoption Cost:
Making this syntax legal is trivial since everyone is
presumably already compatible with the existing standard.
Implicit in the acceptance of this proposal, however is the
incremental cost of late debugging of programs which are in error
but for which no diagnostic has been generated because we have
not required such a diagnostic.
Benefits:
The current state of the world would be unaffected.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Current Practice:
Some implementations already provide this feature.
A few implementations provide alternate keyword-driven extensions
that are incompatible with the IF-BODY:LEGAL extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF (making
it hard to detect errors in code that was developed on systems with
the extended syntax).
Discussion:
MACSYMA ran into this problem.
KMP supports IF-BODY:LEGAL.
Steele and Fahlman support IF-BODY:UNCHANGED.
Moon has no strong opinion.
Fahlman expressed strong concern about the potential precedent which
could be set by using compatibility concerns as a lever to introduce
all kinds of unwanted idiosyncratic extensions present in only one
implementation and no other.
Moon suggested that the mere fact that some people like an extension
is not sufficient reason to put it into the language, but is
sufficient reason to -discuss- putting it into the language.
Steele notes that one of the reasons for including IF in the language
is to have a simple primitive that can easily be recognized, by people
and by program-walkers alike, as being the simplest conditional and
not having implicit PROGNs as do WHEN, UNLESS, and COND.
KMP thinks the language is already so cluttered that worrying about
such a tiny change to IF is unwarranted. He thinks that if the only
concern was primitive simplicity, we should just redefine the layer
at which simplicity is achieved by letting LISP:IF be a macro that
expands into PRIMITIVE:IF which has simpler semantics but which no
one has to be stuck programming with (if they don't want to). You
could argue that users should make their own JDOE:IF macro that has
this extension, but since this is likely to be a common extension, it's
our place to consider it for adoption as part of the standard.
∂29-Apr-87 1404 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:04:18 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:19:45 EDT
Date: Wed, 29 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870429151657.4.GLS@BOETHIUS.THINK.COM>
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
I am not passionate either. AREF-1D has the advantage of brevity.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
This is a good idea.
--Guy
∂29-Apr-87 1406 gls@think.com AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:05:52 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 29 Apr 87 14:04:23 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:20:50 EDT
Date: Wed, 29 Apr 87 15:17 EDT
From: Guy Steele <gls@think.com>
Subject: AREF-1D
To: edsel!bhopal!jonl@navajo.stanford.edu,
navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu, gls@think.com
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-Id: <870429151757.5.GLS@BOETHIUS.THINK.COM>
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
Foo. It just goes to show that I can't remember what's in the book either.
∂29-Apr-87 1501 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 15:01:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 14:17:27 PDT
Date: 29 Apr 87 14:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870429-141727-2814@Xerox>
I put DEFVAR-INIT-TIME in the "we can release this soon" because I
presumed that it was so trivial there would be no objection. Usually its
a mistake to make any such presumptions, but one can always hope....
∂29-Apr-87 1722 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:22:30 PDT
Received: by navajo.stanford.edu; Wed, 29 Apr 87 17:22:02 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01519; Wed, 29 Apr 87 16:33:45 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13102; Wed, 29 Apr 87 16:30:59 PDT
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704292330.AA13102@bhopal.edsel.com>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 29 Apr 87 09:35 EDT
Subject: Issue: PROCLAIM-LEXICAL
In a deep-bound Lisp, it is critically important to be able to distinguish
"global" access/update from "special", or "fluid" access/update. A note
I sent to the CL mailing list about a year ago stressed this point; it
explained the semantic differences and showed some performance consequences.
There were not many replies about it since almost all Common Lisps are
currently shallow-bound [the upcoming Xerox effort will be an exception,
and some parallel research versions of Common Lisp are also an exception]
Since none of these proposals for clarifying the semantics of undeclared
variables propose to do away with "special" variables, then the question
of global/fluid distinction for "specials" is still relevant. So I'm a
bit concerned about the proposal to add yet a third environment, the
"global lexical", which doesn't address this concern.
Consider, for a moment, the example:
(let ((x 1))
(declare (special x))
(load "some-file"))
where the contents of "some-file" are
(setq x (+ x 3))
The historic interpretation is that this SETQ applies to the special
binding of x. To get the effect of setting the global "fluid" binding,
one would have to say something like
(proclaim '(global x))
(setq x (+ x 3))
or like
(locally (declare (global x)) (setq x (+ x 3)))
or use functions like Interlisp's "topval" functions:
(settopval 'x (+ (gettopval 'x) 3))
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the shallow-binding
value cell as both the "global" cell and the "special" cell; For many
reasons, it is very convenient to have the "top-level" fluid environment
be the same as the global environment.
That's why I'm a bit taken aback by your proposal that the "global lexical"
could not share with the global dynamic (fluid) environment. Whereas there
is the demonstrated need for a declaration which distinguishes special
variables from global variables, where is the need for a distinct, yet
parallel, global lexical environment?
-- JonL --
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127770; Wed 29-Apr-87 20:26:29 EDT
Date: Wed, 29 Apr 87 20:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202621.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127778; Wed 29-Apr-87 20:29:19 EDT
Date: Wed, 29 Apr 87 20:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202910.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor FORMAT-OP-C:WRITE-CHAR.
∂29-Apr-87 1844 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 18:44:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 18:45:08 PDT
Date: 29 Apr 87 18:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-184508-3208@Xerox>
Kent, I'll point out again that the proposal should not say "Change the
wording on p. 3241 to say...". The proposal should describe what ANSI
Standard Lisp should do, not what Guy Steele's second edition should
say. The words you use can be pretty much the same, but a number of
folks expressed some sensitivity that the cleanup committee not dictate
wording.
E.g., rather than
" Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment."
Proposal (FORMAT-OP-C:WRITE-CHAR):
The ~C option of format, when given a character with zero bits, will
perform the same action as WRITE-CHAR. (The behavior of FORMAT with the
~C directive given a character with non-zero bits attributes remains
unspecified.)
∂29-Apr-87 1926 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:26:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127905; Wed 29-Apr-87 22:26:18 EDT
Date: Wed, 29 Apr 87 22:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>
Message-ID: <870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I remember some of this being discussed before, and there being some
reason for not doing it that I couldn't remember, so I went back
through some old Common Lisp documents I have held onto. Here's
what I found:
21 Dec 1981 Issue #70 - we discussed the issue of what undeclared
free variable references mean, but couldn't decide. The alternatives
offered weren't very deep:
(a) interpreter and compiler warn
(b) interpreter never warns, compiler is permitted to warn
(c) "status quo" [it said] the interpreter never warns, but the compiler
never warns for top level forms, but is permitted to warn inside functions
21 Dec 1981 Issue #72 - we tentatively introduced a LOCAL declaration,
meaning not SPECIAL. This was by analogy with the UNSPECIAL declaration
of Maclisp and Zetalisp, but we decided to change the name. I don't
think we had completely understood the DECLARE/PROCLAIM distinction
at that time (although we were discussing it) so I'm not sure what
LOCAL meant as a proclamation; I think the idea was just that as a
declaration it could be used to shadow a SPECIAL proclamation.
8/14/82 I found a note of mine saying "there is no way to declare
a variable not special. I guess this got taken out when special was
changed not to be pervasive. This needs to be fixed."
8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
In all later documents, there is special but no unspecial nor local.
This confirmed my memory that a lexical declaration had been put in and
then taken out, but I was unable to find any written rationale for the
decisions, which is what I was really looking for. I didn't go so far
as to search the electronic mail archives (but I don't think they go
back all the way to 1981).
∂29-Apr-87 1951 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:51:22 PDT
Date: Wed, 29 Apr 87 22:53:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@MX.LCS.MIT.EDU
In-reply-to: Msg of Wed 29 Apr 87 16:30:59 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193127.870429.JAR@AI.AI.MIT.EDU>
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
So I'm a bit concerned about the proposal to add yet a third
environment, the "global lexical", which doesn't address this
concern.
I'm having trouble understanding how you count environments. I count a
total of four:
1. lexical LAMBDA-bindings
2. global lexical
3. dynamic LAMBDA-bindings
4. global dynamic
KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
I tend to think of 2 and 4 as being part of 1 and 3. This is consistent
if you imagine that there's an immense cosmic LAMBDA surrounding all
the programs in the world; this LAMBDA binds all possible names.
I have no opinion at this point on the virtues of KMP's amendment.
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the
shallow-binding value cell as both the "global" cell and the "special"
cell...
This proposal is even more restrictive than RESTRICTED. I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. The RESTRICTED proposal seems to give you everything you want
-- it allows you to have a single global value cell in
shallow-dynamic-binding implementations, and it allows the desired
performance advantages in deep-dynamic-binding implementations. Why do
you want to rule out lexically lambda-binding global variables? Does
this have something to do with shallow lexical binding?
If I have told you something you didn't already know, or if you still
don't understand what I'm getting at, how can I make the proposals
clearer?
Jonathan
∂30-Apr-87 0053 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 00:53:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 00:52:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA03157; Wed, 29 Apr 87 23:47:27 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13625; Wed, 29 Apr 87 23:44:42 PDT
Date: Wed, 29 Apr 87 23:44:42 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704300644.AA13625@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 29 Apr 87 22:26 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re :8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
This "Common Lisp meeting" was held at CMU just after the 1982 Lisp
Conference. The "JonL paper" in question could hardly be anything
other than my contribution to that conference. It had a long title
something like "Constant Time Interpretation for Variables, in the
Presence of Mixed SPECIAL/LOCAL Declarations". It described the VAX/NIL
interpreter, and how it processed "special" and "unspecial" declarations
by pushing a block similar to what a lambda-binding would do, and
how the interpretation of a variable reference was resolved by comparing
"declarational level number" with "binding level number". It was full
of cute little acronyms, for which I can blame GLS.
I vaguely remember some flaming about LOCAL declaration being unnecessary
because, unlike in MacLisp, the SPECIAL declaration of Common Lisp wasn't
to be pervasive. As you say, I think the "flamers" totally blew it because
of not understanding the difference between DECLARE and PROCLAIM.
-- JonL --
P.S. The technique described in the above-mentioned paper was strictly
for a shallow-bound, non-parallel implementation. I don't think
I see how to generalize it otherwise.
∂30-Apr-87 1425 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:25:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 14:26:24 PDT
Date: 30 Apr 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142624-4291@Xerox>
I support DEFVAR-INIT-TIME as submitted.
If there is no objection, we can release it as is.
∂30-Apr-87 1429 Masinter.pa@Xerox.COM Re: Procedure for Steele's proposed clarifications
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:29:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 14:29:41 PDT
Date: 30 Apr 87 14:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Procedure for Steele's proposed clarifications
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 13:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142941-4301@Xerox>
Many of the issues that are before us occured in Steele's list of
proposed clarifications, and, even though simple at first glance, seemed
to require the full-blown form.
If there is a subset of the clarifications which we can agree on without
discussion, then I'd be happy to proceed with them; if we all agree, we
can just submit them as a set of "obvious clarifications". I'm a little
skeptical that there are many like that. Do you have some candidates in
mind?
∂30-Apr-87 1459 Masinter.pa@Xerox.COM Re: Status of IGNORE-ERRORS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:59:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:12 PDT
Date: 30 Apr 87 14:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Status of IGNORE-ERRORS
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:25 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu, Daniels.pa@Xerox.COM
Message-ID: <870430-150012-4352@Xerox>
The only thing hanging up the signalling proposal is that that committee
(and mainly Kent Pitman) needs to bring it up before the next X3J13. It
is an excellent proposal and we should adopt it and get on with it.
There's no point in adopting IGNORE-ERRORS when we could get the whole
thing.
This was originally my paraphrase of Pavel's comments, but I've really
written what I think. At the meeting before X3J13 you were pretty
mysterious about your reasons for thinking the error proposal would take
too long, or longer than this committee would take.
Comments?
∂30-Apr-87 1502 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 15:01:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:55 PDT
Date: 30 Apr 87 14:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:37 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870430-150055-4353@Xerox>
In the interest of getting this out of our hair, I think we could
release it as is. As a point for future proposals, I would like to
discourage "status quo" alternatives in enhancement proposals, since
every proposal has an implicit "status quo" alternative, and some of the
arguments are redundant. I had expected you would just elaborate in the
Discussions section, but ... whatever ...
Sometimes this process seems so mind-numbingly bureaucratic...
∂30-Apr-87 1638 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 16:38:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 16:37:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA06279; Thu, 30 Apr 87 16:13:47 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA01123; Thu, 30 Apr 87 16:11:01 PDT
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704302311.AA01123@bhopal.edsel.com>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu,
navajo!KMP%MX.LCS.MIT.EDU@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Wed, 29 Apr 87 22:53:15 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re: KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
Since this "global lexical" environment isn't to be identical with the
"global fluid" environment, then it's a "new" environment as far as
Common Lisp is concerned; that's why I said he was "adding" something.
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
Have I misread anything here? Your proposals were clearly worded enough;
I only wanted to bring up an objection to the idea of having two totally
distinct global environments. I think calling it an "addition" or not
is a really minor point.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you couldn't
lambda-bind anything that had a binding in the global environment. It WAS
that you couldn't lambda-bind anything that was explicitly declared or
proclaimed GLOBAL rather than SPECIAL (or LOCAL?).
In an implementation where the global fluid environment is the same as
the top-level environment (the standard state for virtually all deep
and shallow bound Lisps -- but not for Lisp 1.5), then a SETting
of any variable without a dynamically intervening lambda-binding would
just make a global/top-level binding. This would happen independently
of whether the variable was proclaimed GLOBAL or SPECIAL. But a variable
delcared GLOBAL would only affect the top-level binding; not any
intermediate SPECIAL lambda-bindings.
Do you see the difference here? or does this point need more explication?
-- JonL --
∂30-Apr-87 1818 Masinter.pa@Xerox.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 18:18:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 16:46:05 PDT
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <870430-164605-4496@Xerox>
fyi, this is the reaction from our local array expert...
----- Begin Forwarded Messages -----
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
Subject: Re: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)]
In-reply-to: Masinter.pa's message of 30 Apr 87 14:17 PDT
To: Masinter.pa
cc: pedersen.pa
Don't really like either proposal -- because they seem like hacks
rather than a serious approach to the problem. Also, Common Lisp is
already over-bloated, it just doesn't need creeping featurism -- but
rather a trimming down. After all -- these proposals simply relieve the
user of the very minor chore of making displaced arrays for the rare
instances where that is the natural thing to do -- no real value is
added, but there is a cost in complexity, and possibly performance.
The truth is that if you really want to do multi-dimensioned array
manipulation, you really do want something like APL, or close to it.
Implementing an array calculus -- like APL -- is quite doable (I have
something close to that floating around), and is the right way to go for
heavy array users, but I don't think that functionality needs to be
built into the language.
J.P.
----- End Forwarded Messages -----
∂30-Apr-87 1901 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 19:01:20 PDT
Date: Thu, 30 Apr 87 22:03:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Thu 30 Apr 87 16:11:01 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193809.870430.JAR@AI.AI.MIT.EDU>
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
OK, I see. "Free" means lexically free.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you
couldn't lambda-bind anything that had a binding in the global
environment. It WAS that you couldn't lambda-bind anything that was
explicitly declared or proclaimed GLOBAL rather than SPECIAL (or
LOCAL?).
Since you are implicitly proposing a third kind of declaration (GLOBAL,
in addition to SPECIAL and my proposed LEXICAL), I take this as an
implicit criticism of the proposal; you must consider it inadequate or
else you wouldn't be suggesting this new and different idea. I'm
wondering what
(PROCLAIM '(GLOBAL ...))
gives you that
(PROCLAIM '(LEXICAL ...))
doesn't. Forgetting our differences in conceptual model and terminology
for the moment, the ONLY difference I see between these (assuming the
RESTRICTED proposal), either semantically and pragmatically, is that a
variable that proclaimed GLOBAL cannot be lexically lambda-bound.
Therefore I don't see what GLOBAL adds to my proposal or why you are
suggesting that it's a good idea. (Certainly in the absence of
(PROCLAIM '(LEXICAL ...)), it is a good idea.)
I.e. I don't see how your "global" variables are different from my
"global lexical" variables.
Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive to me, as
long as you buy the idea that there is such a thing as a top-level
(global) environment, which serves as BOTH the top-level lexical
environment and as the top-level dynamic environment (unless KMP has his
way).
Jonathan
∂01-May-87 1536 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 15:36:11 PDT
Received: by navajo.stanford.edu; Fri, 1 May 87 15:35:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA09971; Fri, 1 May 87 13:15:07 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00639; Fri, 1 May 87 13:12:21 PDT
Date: Fri, 1 May 87 13:12:21 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705012012.AA00639@bhopal.edsel.uucp>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!KMP%AI.AI.MIT.EDU@navajo.stanford.edu,
navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Thu, 30 Apr 87 22:03:41 EDT
Subject: Issue: PROCLAIM-LEXICAL
I believe that the deep-binders would be satisfied with top-level
environment being called "global lexical", providing that the "global
special" (or, "global fluid" if you will) is the same. The main issue
is: What does a special reference mean when there is no dynamically
intervening special binding? Is it ok for it to access the "global
lexical" binding? I wouldn't want to go so far as to make an alternative
proposal, providing you agree that this is no problem with the single
top-level environment. [Larry -- could you volunteer some opinion?
This issue will probably affect Xerox's Lisp the most?].
Re: Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive ...
To me, "lexical" means "lexically apparent", or "lexically constrained".
In the example:
(DEFUN FOO (X) (DECLARE (SPECIAL X)) (LIST (BAR X) (BAR X)))
both instances of "X" in the calls to "BAR" are "lexical" with respect
to its binding; but "X" isn't lexically bound, it is dynamically bound.
[Note also; it is not "free".] Consider the (free) occurances of "X" in
some other module, which in fact might access the value of this binding;
they are not "lexically apparent". For this reason -- wanting to talk
about lexical context and not imply anything about the bindings of
variables therein -- I tend to prefer another term for the opposite of
SPECIAL. But I'm not at all enamored with the term LOCAL, or even
UNSPECIAL; LEXICAL would be ok as long as the documentation clearly
stressed this point.
-- JonL --
∂01-May-87 1656 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 16:56:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130001; Fri 1-May-87 19:56:58 EDT
Date: Fri, 1 May 87 19:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU,
Pedersen.pa@Xerox.COM
In-Reply-To: <870430-164605-4496@Xerox>
Message-ID: <870501195646.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
fyi, this is the reaction from our local array expert...
...
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
... they seem like hacks rather than a serious approach to
the problem. ...
My guess is that it looks hackish more from a historical perspective
than it would if you just saw a new edition of the manual that didn't
refer to these as sequence functions. Surely if you were just told from
scratch that arrays were valid arguments to MAP or COUNT, you wouldn't
have thought it even remotely hackish. You'd likely say: "Of course."
I think your view may be skewed by feeling like we'll still have a sequence
functions chapter that will say "Oh, by the way, as a special case, MAP
and count will treat arrays as sequences displaced to their storage."
The argument about displacement is the rationale for the argument (and
for why it won't be efficient) more than advice for how the result might
be presented in the manual.
Pedersen: ... these proposals simply relieve the user of the very
minor chore of making displaced arrays for the rare instances where
that is the natural thing to do -- no real value is added, ...
Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. RPLACA and RPLACD are hard to learn, but they
are taught about in lots of classes and lots of books so people
eventually catch on. Displaced arrays may be taught in some thorough
courses and one or two advanced books, but I bet are largely overlooked.
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean. On the other hand, there's
nothing even remotely unclean about using an operator like MAP or COUNT
on an array if that operator is willing to do the work for you. It's
not the machine instructions that count, it's what the program has to
say in order to make the machine instructions get executed that's of
interest.
Pedersen: ... but there is a cost in complexity, ...
I'd find it easier to remember a rule saying that "SUBSTITUTE does
top-level substitution in aggregate quantities" than one that says
"SUBSTITUTE does top-level substitution in vectors" because
"aggregate quantities" is a natural concept that I've been dealing
with for much longer than programming and "vector" is a domain
specialized (and in this case very arbitrary) restriction on that
natural concept. I'd consider it a simplification if SUBSTITUTE worked
on arrays.
Pedersen: ... and possibly performance. ...
I bet the performance hit is not remarkably large...
* I'd think compilers which can optimize these function calls
based on declarations could optimize this new case just as easily.
* Some implementations do microcode dispatch, so they don't have to
worry. Of the others, though, I'd bet most do a sequential type
dispatch that falls through to an error clause. If you put the
general array case right before the error clause, it's not costing
anyone but the people who want it (because they have to wade through
the other cases).
* Even so, since it's a constant-time operation to do this algorithm
selection and since all of these operations involve loops, the
performance hit even if you took one would be likely to get lost
in the dust.
* Touretzky effectively argues that there may be a speed improvement
because you can just check for type ARRAY and not check that it's
only a 1d array and go straight to business playing with its
elements. In some cases, this can speed things up by making it
possible to remove code that did what he is suggesting are
"gratuitous" error checks.
Pedersen: ... The truth is that if you really want to do
multi-dimensioned array manipulation, you really do want something
like APL, or close to it. Implementing an array calculus -- like APL
-- is quite doable ... and is the right way to go for heavy array users ...
Well, of course, Touretzky says outright in the proposal that he realizes
this is a harder problem and that he doubts that we would be interested
in solving that, but that the solution to the simpler problem would be
significantly interesting to him certainly and perhaps to others (a
claim that I think he gives a credible case for).
Moreover, the more interesting case is for people who are -not- heavy
array users. They just have one array and they're in some place where they
want to count certain elements. Having to write a routine to do this can
distract from the true purpose of the function, which may be unrelated
to the array issue.
I was recently looking back over a lot of old Maclisp code I wrote
around 1979-80. I was struck by the number of times I'd written utility
functions that got used only once -- many things that now are (fortunately)
available in the system. Getting up to a conversational level with Lisp
took most of the effort -- the programs were trivial by modern standards.
I had friends who wrote shorter (but I'd say less intelligible) programs
where they didn't take the time to abstract things out and so in the
middle of some program there'd be a couple of nested DO loops taking the
MAX of something which was not very relevant in the grand scale of things,
but which took up a lot of syntactic space.
I think it's reasonable for us to consider minor extensions that aid
this end of just making certain utilities be common so that they needn't
be written be written time and time again unnecessarily. I think this is
what Common Lisp is about.
∂01-May-87 1933 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:33:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:34:05-EDT
Date: Fri, 1 May 1987 22:34 EDT
Message-ID: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987 15:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have had applications which for various reasons I can't go
into in detail where I needed to have a keyword which no one
but myself would use.
Come on, doesn't anyone have a short, coherent example that demonstrates
the need for a non-keyword as a "keyword" argument? If the goal is to
have publically accessible functions that take hidden arguments, I'd
like to see an explanation of the need for this. Seems to me like a
pretty bogus way to do encapsulation, but maybe I'm missing something.
Testimonials are fine, but it's going to be hard to sell this proposal
without a coherent explanation.
-- Scott
∂01-May-87 1947 FAHLMAN@C.CS.CMU.EDU ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:47:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:48:23-EDT
Date: Fri, 1 May 1987 22:48 EDT
Message-ID: <FAHLMAN.12299040692.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
In-reply-to: Msg of 22 Apr 1987 16:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I don't like this proposed extension. It seems confusing and dangerous
to do the destructive operation in some cases and a copy in other cases.
I think that I would be more comfortable with some sort of COPY-ARRAY
function, though I'd need to see the details in order to be sure.
-- Scott
∂01-May-87 2030 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 20:29:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130098; Fri 1-May-87 23:30:18 EDT
Date: Fri, 1 May 87 23:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Message-ID: <870501233004.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have a Version 2 of this issue waiting for Moon to look it over before sending it
out. The following text is excerpted from that proposal. Does it look any better
to you?
Rationale:
By allowing symbols other than keyword symbols as keywords, we provide
a more private communication channel between functions.
Also, applications such as the emerging object-oriented standard which
must reliably merge keywords coming from different sources (some internal
and some user-supplied) can work more reliably by exploting this new
partitioning of keyword names. For example, a public routine MAKE-FOO
might need to accept arbitrary keywords from the caller and might want
to pass those keywords along to an internal routine using keywords of
its own.
For example,
(IN-PACKAGE 'SYSTEM)
(DEFUN MAKE-INSTANCE (TYPE &REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-INSTANCE-INTERNAL TYPE 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs since the only way that could happen
is if someone had done (MAKE-INSTANCE 'ZEBRA 'SYSTEM::EXPLICIT NIL), or
if the user was programming explicitly in the SYSTEM package, either of
which is an implicit admission of willingness to violate SYSTEM's modularity.
∂01-May-87 2037 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 20:37:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 23:26:54-EDT
Date: Fri, 1 May 1987 23:26 EDT
Message-ID: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
In-reply-to: Msg of 23 Apr 1987 02:07-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Larry's status report says that this issue has been agreed...
I never agreed to this, and I think you are overlooking something.
Well, it should have been "agreed by those present at the pre-X3J13
meeting", I guess.
Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw. There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error"). It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally. I prefer signalling an error, because I firmly believe
that the program is ill-formed.
I think you've spotted a case that the rest of us missed. At least, it
didn't come up in earlier discussion. I'm not completely sure what is
right, but I'm inclined to agree that "signals an error" is the right
thing here, rather than just allowing the throw whose tag is outermost
to win. I've got a hunch that trying to do the latter would just
introduce another layer of subtle problems.
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
-- Scott
∂01-May-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:15:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:16:48-EDT
Date: Sat, 2 May 1987 00:16 EDT
Message-ID: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 1 May 1987 23:30-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Yeah, that's the sort of example I was looking for. I see what you're
driving at now, but the example of Make-Instance doesn't seem terribly
compelling. One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg, since the target function has to be ready to handle
Explicit in any event. Seems like you're just muddling things together
and that the callee will have to un-muddle them again.
In any event, I suppose that this is a legitimate style, even though I
think it is ugly and probably inefficient. Since the proposed change is
fairly harmless, this example probably provides enough motivation for it.
-- Scott
∂01-May-87 2128 FAHLMAN@C.CS.CMU.EDU Issue DEFVAR-INIT-TIME (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:27:55 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:29:01-EDT
Date: Sat, 2 May 1987 00:28 EDT
Message-ID: <FAHLMAN.12299059010.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: Msg of 23 Apr 1987 16:59-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
This looks OK to me.
I believe that the cause of the confusion is really the statement that
the initial value form is not evaluated unless "it is used". Better to
say that INITIAL-VALUE is evaluated if and only if the variable does not
already have a value. Then I think that there would be no confusion
about the time of evaluation, though it can't hurt to spell this out
explicitly.
-- Scott
∂01-May-87 2145 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 21:44:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130133; Sat 2-May-87 00:45:09 EDT
Date: Sat, 2 May 87 00:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Message-ID: <870502004454.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sat, 2 May 1987 00:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg ...
What if MAKE-INSTANCE-INTERNAL takes 47 such internal keywords? Just
because I only used one in the call doesn't mean that's all it receives.
Would you have me pass all 47 internal arguments on every call?
Also, the caller of MAKE-INSTANCE might be within package SYSTEM and so
it might not be an abstraction violation for him to pass other packaged
symbols. That means that more keywords than those you see might be being
received in the main arglist, though presumably none that the caller
worries are going to be overridden by MAKE-INSTANCE.
Or there might be other situations in which keyword-style calling is
more important than in the particular call that you have there.
I could add some of these issues to the add rationale, too, if you like.
Almost by definition, any two-line example is not going to leave you
feeling satisfied about something which is claimed to be useful in
complex situations involving modularity boundaries.
Anyway, the fact that you can figure out what is being hinted at by the
small example makes me feel like the example did its job.
∂02-May-87 0707 FAHLMAN@C.CS.CMU.EDU DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 07:07:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 10:08:35-EDT
Date: Sat, 2 May 1987 10:08 EDT
Message-ID: <FAHLMAN.12299164519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
In-reply-to: Msg of 25 Apr 1987 03:25-EDT from Guy Steele <gls at think.com>
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
Nothing is foolproof because fools are so ingenious. (Who said that?)
I don't think that it is a good idea to go back and diddle with these
old problems at this point. Destructive operations on lists are tricky
in N other ways as well, so you've got to stop and think. I wouldn't
mind a "chatty" compiler mode that warns of a possible problem whenever
it sees a DELETE not in a setting form, but this is not a standards-type
issue.
Since you signed this "Quux", I'll assume that you don't really want to
push it.
-- Scott
∂02-May-87 1143 FAHLMAN@C.CS.CMU.EDU IF-BODY (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 11:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 14:43:57-EDT
Date: Sat, 2 May 1987 14:43 EDT
Message-ID: <FAHLMAN.12299214648.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY (Version 5)
In-reply-to: Msg of 27 Apr 1987 18:21-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I hate to keep beating on this, but we're working on developing internal
procedures for handling controversial cases, and it probably is worth
trying to debug these procedures on a stupid case like this before
something really hard comes along. I think we've got the wrong model
here for dealing with controversial things. It is unreasonable to ask
one person to produce a balanced presentation that fairly summarizes all
points of view, including views that he disagrees with.
KMP's latest version of the IF-BODY proposal is a case in point. It
represents a good-faith attempt on his part to present a balanced
discussion of the issues, but the result is nevertheless unbalanced in
subtle ways toward his point of view. I'm not trying to dump on KMP
here -- if I had written the summary, I'm sure it would be even more
biased the other way.
KMP states at the outset that some implementations, if allowed to, will
implement this extension, and that these extended implementations will
"typically" not generate a warning. Later he argues that encouraging
(but not requiring) a warning is inadequate, because an implementation
that adds this feature must think it is a good idea, and you don't warn
about good ideas. This ignores the possibility of a "warn me about any
non-portable code" compilation mode, which is the right solution
(assuming this IF-BODY problem is troublesome enough that it is worth
fixing at all). If an implementor doesn't choose to support such a
mode, fine; that's between him and his customers. But don't ask the
rest of us to mess up the language in order to make that
implementation's users more comfortable -- if the vendor doesn't want to
employ the obvious simple technique for solving this problem, then it
presumably isn't worth solving. I've stated this view N times before
and this "somebody prepare a summary" process keeps eviscerating the
argument. Again, it is the process that is at fault, not the people
doing the summarizing.
It seems to me that the process should go something like this: Person X
proposes a compatible extension. If, after some discussion, consensus
is reached on some (possibly amended) version of the extension, we put
that version forward as a proposal, with some sort of joint rationale in
the discussion section. If the committee doesn't like the proposal and
can talk the proposer into dropping it, fine, we drop it. If there is
no consensus in favor of the change, but the proposer wants to present
the matter to the full X3J13, then he should prepare the most persuasive
argument he can muster -- none of this "balance" stuff. Then, in the
discussion section, the opposition gets to have its say. The point is
that each side of the case must be argued by someone who believes in it.
Just like the lawyers. I suppose that in some cases, there might be
more than one dissenting opinion: various people might dislike a
proposal for different reasons.
There remains the question of who gets the last word. We could iterate
until quiescence or exhaustion is reached, flip a coin, or establish
some arbitrary guideline. I guess I'd say that the proposer gets his
say, then the negative voices, and finally the proposer gets a short
rebuttal (confining himself to answering what the opposition said,
rather than introducing new arguments). The result is concatenated, not
summarized, for presentation to the outside world.
The above assumes that the question is whether or not we should adopt
some change. In a situation where there are N positive proposals to
choose from, all with their advocates, then a FOO:A, FOO:B, FOO:C
approach is appropriate. The arguments in favor of each position should
be presented by the advocates of that position, if any exist. In the
case of a yes/no question, it is silly to have separate FOO:YES and
FOO:NO proposals.
-- Scott
∂02-May-87 1220 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 12:20:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 15:21:49-EDT
Date: Sat, 2 May 1987 15:21 EDT
Message-ID: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Msg of 28 Apr 1987 14:13-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have no strong opinion on this proposal. It doesn't look to me like
it would add much confusion, it wouldn't be too hard to implement, and
apparently some people would find it useful. So I guess I'm mildly in
favor of either the GENERALIZE or the MODIFIED version.
I would not like to see this leave committee in the current format.
Maybe KMP, Touretzky, Rees, and anyone else who cares can work out a
single proposal that they all like. The paths not taken can be
mentioned in the discussion section.
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In choosing issues to introduce in the future, we probably should lean
toward doing clarifications first and saving extension for later.
-- Scott
∂02-May-87 1313 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:13:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:13:50-EDT
Date: Sat, 2 May 1987 16:13 EDT
Message-ID: <FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 28 Apr 1987 16:35-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
<Is JAR on CL-CLEANUP now? If not, we should all include him in the
address list while discussing this.>
I think that this proposal is confused. The current rule for handling a
reference to a variable that is neither bound nor declared is
unambiguous: the variable is assumed to be special. There is no
ambiguity and no need for clarification. Whether we want to change this
is another question, and an interesting one.
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal. The more
of this a compiler does, the better it is as a debugging aid (up to the
point where the "crying wolf" effect sets in because too many spurious
warnings are being generated). The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo. In the latter case, I want to see a warning. If you
tell me that I can can't use a warning here because it looks too much
like an error, then I'll have to create yet another kind of compiler
output ("mild suggestion?") with which I can report these things.
I prefer to retain the term warning for this, and to use the term "error"
when there really is an error.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Then people who hate to see any warnings can get rid of them, and those
of use who use them for debugging can have them. But I see nothing
unacceptable or even uncomfortable about the status quo. Probably the
spec should explaint he difference between an error and a warning rather
than leaving this to the reader's imagination.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free. But we should
not muddle this into a discussion of the current rules or the difference
between warnings and errors in the compiler.
-- Scott
∂02-May-87 1324 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:24:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:25:02-EDT
Date: Sat, 2 May 1987 16:24 EDT
Message-ID: <FAHLMAN.12299233050.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C (Version 2)
In-reply-to: Msg of 29 Apr 1987 12:38-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support this proposl. I think that the presentation should be
simplified before it goes out. Most of the lengthy discussion in the
problem description is unnecessary. This is a simple clarification.
-- Scott
∂02-May-87 1340 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:30:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:31:09-EDT
Date: Sat, 2 May 1987 16:31 EDT
Message-ID: <FAHLMAN.12299234147.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PRINC-CHARACTER (Version 2)
In-reply-to: Msg of 29 Apr 1987 15:46-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
-- Scott
∂02-May-87 1616 JAR@AI.AI.MIT.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:16:03 PDT
Date: Sat, 2 May 87 19:18:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Is JAR on CL-CLEANUP now? Yes.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194617.870502.JAR@AI.AI.MIT.EDU>
I'm on CL-CLEANUP.
∂02-May-87 1655 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:55:26 PDT
Date: Sat, 2 May 87 19:58:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194629.870502.JAR@AI.AI.MIT.EDU>
Date: Sat, 2 May 1987 16:13 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example. If you declare the variable
special, you will change the semantics of the program. In this example
you would also have to rename every X that's lexically bound; being an
extremely non-local transformation, this is unacceptable.
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal.
I basically agree with this, but you should note that every other sort
of warning is avoidable. E.g. an unreferenced bound variable is often a
result of a program error, but when it's not it can be dealt with by
(DECLARE (IGNORE ...)); an OR with only one subform can be a symptom of
a misplaced parenthesis, but where it's the right thing there are ways
to get around the problem (make your macros smarter...). But in this
case the only way to get rid of the warning is either by
alpha-converting or by making the program possibly incorrect, which is
definitely unfriendly.
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Unacceptable in this case (unless we adopt BY-THE-BOOK); many warnings
are quite desirable. I would say a warning is OK if either it indicates
that an error will happen at run time, or if the code is truly is dubious
style AND there is an easy way to fix or annotate the code so that the
warning goes away.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed it,
although if you only looked at the summary at the top and not the rest
of the message, that would explain it; the introduction is admittedly
misleading. I'll fix that next time around.
Like I said in the "Status:" line, this is very preliminary.
Jonathan
∂02-May-87 1720 FAHLMAN@C.CS.CMU.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 17:20:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 20:20:35-EDT
Date: Sat, 2 May 1987 20:20 EDT
Message-ID: <FAHLMAN.12299275925.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Is JAR on CL-CLEANUP now? Yes.
In-reply-to: Msg of 2 May 1987 19:18-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Good. Wasn't sure if you were seeing things routinely or if KMP was
just passing you selected tidbits.
-- Scott
∂02-May-87 1855 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 18:55:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 21:56:52-EDT
Date: Sat, 2 May 1987 21:56 EDT
Message-ID: <FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 2 May 1987 19:58-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
In reply to JAR:
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example.
...
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
OK, if you really want to use the same names for your specials and your
lexicals, then indeed there is no good way to get rid of the warning. I
hardly ever do this, so I missed your point. When I see that warning in
a case like your example program, it tells me that it's time to rename
something, not that I should find some way to inhibit the warning with a
declaration.
I assume that we're not going to consider any radical proposals for the
handling of specials, such as separating the name spaces by making the
*foo* syntax mandatory for specials. If we stay close to the status
quo, it seems to me that we really should go ahead and add a LEXICAL
declaration and a LEXICAL proclamation so that those pervasive special
proclamations can be cancelled or shadowed. I haven't heard any good
arguments against this in the last N years. The need to eliminate
spurious "not declared or bound" warnings is one argument in favor of
this change, but it would be a useful change for other reasons in any
case.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
No difference in principle. Both conditions are suspicious and worth a
warning, in my view, but how such warnings are handled is up to the
implementor. It is desirable to emit these warnings when the suspicious
condition is noticed; that way the location of the problem is marked and
the user has the option of aborting the compilation. In the case of
undefined functions, forward references are particularly common, so most
implementations wait till the end of the compilation before emitting the
warning. In the case of undeclared specials, there does not seem to be
a good reason to wait, so we warn at once.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed
it...
I didn't miss it. Your GENERAL and RESTRICTED proposals seem to re-open
a debate that we had some time ago on "global" or "global lexical"
variables and what their semantics should be. A lot of hairy issues
came up in that discussion, and I didn't see those issues being
addressed here. So my suggestion was that we ought to separate this
issue from the business about inhibiting warnings and try to come up
with a comprehensive proposal on global variables -- comprehensive in
the sense that we try to deal with all the issues raised in the earlier
discussion.
-- Scott
∂04-May-87 1056 Masinter.pa@Xerox.COM Issue priority
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 May 87 10:56:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAY 87 10:54:17 PDT
Date: 4 May 87 10:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue priority
to: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870504-105417-2905@Xerox>
We've been asked by some members of the object proposal to quickly
address the issues that they are waiting on.
Those issues include:
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-TYPE
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I didn't see any strong objections to these proposals, except for the
way in which they were worded.
If you'd like to discuss any of these issues, you will make my life
simpler if you will send separate messages about each.
∂04-May-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 May 87 14:23:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131431; Mon 4-May-87 17:22:42 EDT
Date: Mon, 4 May 87 17:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
References: The message of 23 Apr 1987 02:07-EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
The message of 29 Apr 1980 16:09-EDT from Jon L White <JONL at MIT-MC>
Message-ID: <870504172241.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 1 May 1987 23:26 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In-reply-to: Msg of 23 Apr 1987 02:07-EDT
from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
...
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
Personally, I consider the meaning of this to be well-formed. It'd be
sad for a programmer to get into this, but I think that in this case
the user has pretty clearly asked to have a loop that cannot be exited
and deserves to have that request carried out.
Consider how ridiculous it would have looked on Star Trek when they
needed to divert the computer's attention and said "Computer, compute to
the last digit the value of pi". If I recall, Spock makes a remark like
"As you know, the value of pi is a transcendental number without
resolution. ... The computer will work on this problem to the exclusion
of all else ...". Imagine how frustrated he'd have been if the computer
had refused to execute the command because it didn't seem like he really
meant what he said.
Well, ok, so this isn't the most likely scenario. But the truth is,
as Prof. Bill Martin said once in a linguistics class I took from him --
We create syntax in a language not to allow us to say the things that
are obvious, but so that we can say things that are not obvious. If we
didn't need to say things that were not obvious, we'd just jumble all
the words together and assume people would figure out some uniquely
determined, obviously useful interpretation. In fact, we make careful
rules to allow us to say bizarre things not so we can say bizarre things
all the time, but so that if there comes a time to say such things, we
won't be at a loss for words.
By the way, I did once write a CL program that wanted the semantics that
Moon claims are implausible. In Common Lisp, there was no portable way to
make a Lisp have a Macsyma toplevel (ie, where the vendor's abort character
would return me to Macsyma and not to Lisp). So I wrote something which did
effectively:
(DEFUN MACSYMA-TOPLEVEL ()
(PROG ()
LOOP (UNWIND-PROTECT (REALLY-MACSYMA-TOPLEVEL)
(GO LOOP))))
so that people who'd invoked Macsyma toplevel couldn't get back to toplevel
lisp. So while it might be rare, it's not unthinkable that someone could really
write this and mean what they said...
As such, I don't rate this desire to let the user intervene at the same
level of importance that Moon does. However, since I do find it an
interesting issue, I'm willing to entertain the issue for discussion
for now without prejudice to its ultimate importance.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
If we did make this illegal, I'm curious exactly what Moon would want to
have happen here. The most plausible scenario I can come up with that fits
in this hypothetical framework is the following (which is essentially like
what Scott is suggesting) ...
THROW could notice that it was going to THROW to a point inside
a THROW which was already active. At this point, it could signal
a SERIOUS-CONDITION (some type which was not a subtype of ERROR),
so that IGNORE-ERRORS did not catch the condition, but that did
have a default handler that would force entry into the debugger.
This would allow an opportunity for user-intervention.
The debugger could offer options which should include:
* Going ahead with the inner THROW (and discarding the outer
THROW attempt).
* Exiting from this UNWIND-PROTECT cleanup body and continuing
the ongoing THROW.
* Blowing away the process without running its UNWIND-PROTECT
cleanups.
This would allow for user intervention without precluding what
I believe to be the clean semantics (choice C). I'm suspicious
of any choice which doesn't even allow the user to get style-C
semantics if that's what he wants.
Dave, is this the sort of thing you're proposing? If not, could
you please sketch what you are suggesting for contrast?
By the way, I ran across the following piece of mail the other day
while looking around for something else. I just thought you'd be
interested to know that this problem is as old as UNWIND-PROTECT
itself; the message is from only a few days after UNWIND-PROTECT
was first installed in Maclisp and although the bug is not like
the one we're discussing, the test scenario is a lot similar to
the code sketch Moon did above...
-----Forwarded Message Follows-----
Date: 29 April 1980 16:09-EDT
From: Jon L White <JONL at MIT-MC>
To: KMP at MIT-MC, RWK at MIT-MC
cc: BUG-LISP at MIT-MC
Subject: UNWIND-PROTECT
On the 15th of Feb, KMP sent out a bug notice about UNWIND-PROTECT
losing, for which I made the diagnosis that ERRSET was not saving
and restoring the UNREAL flag. The test case is
(DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ)))))
Well, I found a way to fix ERRSET without taking more pdl locations,
and the assembled code (already initialized) is on LISP;BBLISP 995QIO.
...
∂04-May-87 1919 FAHLMAN@C.CS.CMU.EDU Issue priority
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 May 87 19:19:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 4 May 87 22:18:19-EDT
Date: Mon, 4 May 1987 22:18 EDT
Message-ID: <FAHLMAN.12299821653.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue priority
In-reply-to: Msg of 4 May 1987 13:56-EDT from Masinter.pa at Xerox.COM
KEYWORD-ARGUMENT-NAME-PACKAGE
I believe that KMP is working on a version that explains why a change is
needed. The lack of such an explanation was my only real objection.
FUNCTION-TYPE
On my queue, but I've got a funding proposal to get out by the end of
the week, so this stuff won't get worked on until next weekend. If
anyone else can grab it sooner, feel free.
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I don't think we currently require structures to be a disjoint
type from vectors, etc., though this has been talked about. So that
should be part of any proposal.
∂05-May-87 1416 pedersen.pa@Xerox.COM Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 May 87 14:15:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 87 14:15:02 PDT
Date: 5 May 87 14:14 PDT
From: pedersen.pa@Xerox.COM
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 1 May 87 19:56 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu,
Dave.Touretzky@C.CS.CMU.EDU, Pedersen.pa@Xerox.COM
Message-ID: <870505-141502-1099@Xerox>
Pitman:
"Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. ... Displaced arrays may be taught in some
thorough
courses and one or two advanced books, but I bet are largely
overlooked...
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean."
I find a certain inconsistency in your argument that constructing
displaced-arrays is obtuse and unesthetic, while at the same time
stating that multi-dimensional arrays are naturally operated on as
vectors with elements laid out in row-major order. After all,
displaced-arrays are the only mechanism in common lisp that allows one
to adopt that view, and as such are indispensible. Indeed, one might
argue that for the inexperienced Lisp user, who has some knowledge of
"C" or "FORTRAN", displaced-arrays map directly into conventional use of
pointers into arrays.
On a more constructive note -- it seems like a small addition to the
array mechanism might address most of our concerns. Consider:
(defun flatten-array (array)
(cond ((vectorp array) array)
((arrayp array)
(make-array (array-total-size array)
:element-type (array-element-type array)
:displaced-to array))
(t (error "Not an array: ~s" array))))
then "flatten-array" may be used in combination with sequence functions
to achieve the desired semantics, and would have the advantage of making
clear the intention of a code fragment. A primitive like "flatten-array"
is useful in other contexts as well, and would complement a
"row-major-aref" primitive.
J.P.
∂10-May-87 1154 FAHLMAN@C.CS.CMU.EDU [RAM: exiting from unwind protects]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 11:54:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 14:54:06-EDT
Date: Sun, 10 May 1987 14:54 EDT
Message-ID: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [RAM: exiting from unwind protects]
I find the following pretty persuasive...
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
To: fahlman
Re: exiting from unwind protects
ReSent-Date: Sun 10 May 87 10:56:56-EDT
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: fahlman@C.CS.CMU.EDU
ReSent-Message-ID: <12301270482.15.RAM@C.CS.CMU.EDU>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions. In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
If I had ever been screwed by this, I would think differently. I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form. Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
Rob
∂11-May-87 1051 RPG Draft of revised FUNCTION-TYPE
∂10-May-87 1852 FAHLMAN@C.CS.CMU.EDU Draft of revised FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 18:52:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 21:51:36-EDT
Date: Sun, 10 May 1987 21:51 EDT
Message-ID: <FAHLMAN.12301389651.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SAIL.STANFORD.EDU
Cc: masinter.pa@XEROX.COM
Subject: Draft of revised FUNCTION-TYPE
Dick,
I said I'd give you a shot at this before sending it to the whole
Cleanup list. Want to make a pass and see if this captures what we all
agreed to. I'm not too confident of my ability to use the right terms
for these lexical variables and things, so please keep an eye out for
that. I'm CC'ing Masinter just so he'll know that progress is
progressing progressively. It would be good to get thsi out within a
few days, since the CLOS people seem to need this to be settled.
-- Scott
---------------------------------------------------------------------------
To: cl-cleanup at SAIL.STANFORD.EDU
Re: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
fahlman@c.cs.cmu,masinter.pa@xerox/su
Function Type Proposal
I think it looks good as you have it. Fire away.
-rpg-
∂11-May-87 1256 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 12:56:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 15:55:55-EDT
Date: Mon, 11 May 1987 15:55 EDT
Message-ID: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
∂11-May-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137159; Mon 11-May-87 17:18:50 EDT
Date: Mon, 11 May 87 17:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870511171840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 15:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
I (apparently somewhat belatedly!) approve of FUNCTION-TYPE:REDEFINE
except with the following two caveats:
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
Common Lisp currently defines a type-specifier named COMPILED-FUNCTION.
Is this a proposal to remove it? I would probably support such a proposal,
but it should be explicit.
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
The phrase "signal an error if it is unable to do so" is new. My
problem is that the concept of "unable to compile" is not defined and is
open to varying interpretations. For example, does this mean that if
any compiler warnings are issued, COMPILE should signal an error at the
conclusion of the compilation? Also, if we assume that the word
"should" used on CLtL p.439 is covered by the discussion of "must" on
CLtL p.6, then right now this "is an error" rather than "signals an
error." Also, the specification that COMPILE is a no-op if called with
one argument and the symbol's definition is already compiled appears to
be a change from CLtL, although CLtL is so ambiguous it's hard to be
sure.
Unless there are reasons that these changes to COMPILE must be
incorporated into this proposal, I think it would be better to deal with
them as a separate proposal. For this proposal, I suggest confining the
discussion to how COMPILE defaults its second argument. I would say
that if the second argument is not supplied, the first argument "should"
be a symbol that is FBOUNDP and for which the implementation is able to
reconstruct the lambda-expression corresponding to its definition. So
the only change from CLtL would be to change "a definition that is a
lambda-expression" to "a definition from which the implementation is
able to reconstruct a lambda-expression". Possibly we should try to state
some necessary conditions under which the implementation is required to
be able to recover the lambda-expression. Possibly we shouldn't; this
only points out the inherent uselessness of 1-argument COMPILE in
portable programs.
Alternatively, we could take the coward's way out and make both
arguments to COMPILE be required, or, even better, make COMPILE take
only one argument, which must be a lambda expression, and neither read
nor write SYMBOL-FUNCTION.
∂11-May-87 1443 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:41:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137185; Mon 11-May-87 17:39:09 EDT
Date: Mon, 11 May 87 17:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-STREAM
Status: New issue, but easy to agree on
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
The book says that a stream can be used as an argument and converted to
a pathname, but pathnames only name files, not other sources or sinks
of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream
that is or was open to a file.
Rationale:
This is probably what the designers of Common Lisp intended.
This is the only thing that can be implemented without large changes to
the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since I didn't say "signals an error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: None.
Aesthetics: Makes language a little cleaner.
Discussion: None yet.
∂11-May-87 1502 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 15:02:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137213; Mon 11-May-87 18:01:19 EDT
Date: Mon, 11 May 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-SYMBOL
[Note that this is not the same issue as PATHNAME-STREAM]
Status: New issue
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Category: INCOMPATIBLE CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected.
Rationale:
The feature of accepting a symbol was copied by Common Lisp from Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a symbol
here was that it did not have strings at all. However, the feature has been
long since removed from Zetalisp, since it was found to be a source of bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file named
"nil" on some perhaps unexpected directory.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that check
the type of this argument, program error checking will be improved.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings.
Aesthetics: Improved by the change.
Discussion:
The only user feedback on this issue I've seen was a bug report that
MERGE-PATHNAMES was in error because it accepted symbols.
∂11-May-87 1803 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:03:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:02:25-EDT
Date: Mon, 11 May 1987 21:02 EDT
Message-ID: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 18:01-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-SYMBOL:NIL.
It would be nice if someone would undertake a complete review of the
pathname situation. Seems to me that many problems lurk in here. But
the desire for a comprehensive solution shouldn't prevent us from
patching things that need to be patched.
-- Scott
∂11-May-87 1807 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-STREAM
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:05:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:04:29-EDT
Date: Mon, 11 May 1987 21:04 EDT
Message-ID: <FAHLMAN.12301643218.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-STREAM
In-reply-to: Msg of 11 May 1987 17:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
-- Scott
∂11-May-87 1901 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:01:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137484; Mon 11-May-87 21:59:47 EDT
Date: Mon, 11 May 87 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511215932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
Status: Revised after discussion
Problem Description:
CLtL says that only keyword symbols can be used as non-positional argument
names in &key parameter specifiers.
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.
Rationale:
As Common Lisp is currently defined, if someone wants to define a function
that accepts named (rather than positional) arguments whose names are
symbols in packages other than the KEYWORD package, they cannot use &KEY.
Instead, they have to duplicate the &KEY mechanism using &REST, GETF,
and (if they want error checking of argument names) DO. This suggests that
the restriction of &key to only keyword symbols is arbitrary and unnecessary.
Note that the "rationale" box on p.62 of Common Lisp: the Language is an
argument in favor of requiring non-positional argument names to be symbols,
and not allowing numbers, but does not speak to the issue of whether or not
those symbols should be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword symbols
arises when the set of non-positional arguments accepted by a function is
the union of the sets of non-positional arguments accepted by several other
functions, rather than being enumerated in a single place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability is
the draft proposal for an object-oriented programming standard. It will
have generic functions that accept non-positional arguments and pass them on
to one or more applicable methods, with each method defining its own set of
arguments that it is interested in. If this proposal is not adopted, either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.
A second example of a Common Lisp application that requires this capability
is private communication channels between functions. Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs, since the only way that could happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user was
programming explicitly in the FOOLAND package, either of which is an implicit
admission of willingness to violate FOOLAND's modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in understanding
the impact of the proposal.
Change wording which refers to non-positional arguments as being introduced
by keyword symbols to simply refer to those arguments being introduced by
symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
Also, the word "keyword" in the first complete sentence on p.62 would
be changed to "symbol" for similar reasons.
Add extra wording on p.60 to explain that by convention keyword symbols
are normally used as non-positional argument names, and that all functions
built into the Common Lisp language follow that convention. A language
manual might or might not choose to describe the circumstances in which
it is appropriate not to follow this convention.
Add examples to illustrate this behavior. For example, on p.64 the
following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the restriction
that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a keyword
argument name, but allow all non-NIL symbols. (One Symbolics version that
was checked had this bug.)
Adoption Cost:
No existing programs will stop working. Some implementors might have to
rearrange their error checking slightly, but it should be very easy.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
Benefits:
This will help with the object-oriented programming standard, among other
things.
Conversion Cost:
None.
Aesthetics:
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
In any case, users who do not want to use the extended functionality
can generally avoid it.
Discussion:
Moon generated the original version of this proposal and supports it.
He thinks that if Common Lisp truly has a restriction that only keyword
symbols can be used as keyword names in calls to functions that take
keyword arguments, it will be more difficult to come up with an
object-oriented programming standard that fits within Common Lisp.
Pitman supports this proposal.
There was some question in the committee about whether the rationale
for the proposal was believable. I hope this version of the proposal
has resolved any doubts.
∂11-May-87 1907 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:07:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137493; Mon 11-May-87 22:05:42 EDT
Date: Mon, 11 May 87 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Message-ID: <870511220522.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 21:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I favor PATHNAME-SYMBOL:NIL.
To avoid any confusion: do you mean PATHNAME-SYMBOL:NO, or is
PATHNAME-SYMBOL:NIL a different proposal?
∂11-May-87 1940 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 19:40:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 22:39:37-EDT
Date: Mon, 11 May 1987 22:39 EDT
Message-ID: <FAHLMAN.12301660525.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 22:05-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Clarification:
I favor PATHNAME-SYMBOL:NO.
-- Scott
∂12-May-87 0728 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 07:28:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 10:27:27-EDT
Date: Tue, 12 May 1987 10:27 EDT
Message-ID: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: Msg of 11 May 1987 21:59-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may noit be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
-- Scott
∂12-May-87 0930 Gregor.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 09:30:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 87 09:26:41 PDT
Date: 12 May 87 09:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 11 May 87 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <870512-092641-3405@Xerox>
I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY.
∂12-May-87 1158 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 11:58:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138111; Tue 12-May-87 14:56:28 EDT
Date: Tue, 12 May 87 14:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Message-ID: <870512145619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 12 May 1987 10:27 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
Thanks.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may not be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
I was using "non-positional-argument-name" where you used "keyword-indicator".
We have to do something about the terminology. I like "argument name" a little
better than "keyword indicator", although the former has the problem that people
might confuse it with "parameter name", since experience has shown that it's
virtually impossible for anyone to remember which are the arguments and which
are the parameters.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
I agree with this, except that the syntax actually has two parentheses,
i.e. ((keyword-indicator variable)), to distinguish it from (variable default).
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
We can take "lambda-list-keywords", which aren't "keyword-symbols" either,
as a precedent.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
I don't care about NIL being allowed or disallowed. As a language
designer, it seems like a weird restriction to disallow it, even though
there is no earthly reason to use it. As a commercial vendor, I won't
complain if we don't have to fix the bug that we currently disallow it.
I'll defer to anyone who has a strong opinion about this.
∂12-May-87 1258 gls@Think.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 12:57:56 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 15:59:54 EDT
Date: Tue, 12 May 87 15:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu
In-Reply-To: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Message-Id: <870512155947.2.GLS@BOETHIUS.THINK.COM>
Date: Sat, 2 May 1987 15:21 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
...
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In this instance, note that a NIL result could be confused with an
empty list of subscripts, the natural result in the case of a
zero-dimensional array.
--Guy
∂12-May-87 1430 gls@Think.COM Issue: FUNCTION-TYPE (version 3)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:29:52 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:31:34 EDT
Date: Tue, 12 May 87 17:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-Id: <870512173129.7.GLS@BOETHIUS.THINK.COM>
I support FUNCTION-TYPE:REDEFINE.
∂12-May-87 1456 gls@Think.COM Issue: PATHNAME-SYMBOL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:02 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:58:18 EDT
Date: Tue, 12 May 87 17:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175812.2.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-SYMBOL:NO.
∂12-May-87 1457 gls@Think.COM Issue: PATHNAME-STREAM
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:55 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:59:14 EDT
Date: Tue, 12 May 87 17:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175910.3.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
∂12-May-87 2104 Moon@STONY-BROOK.SCRC.Symbolics.COM [RAM: exiting from unwind protects]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:04:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138596; Wed 13-May-87 00:02:53 EDT
Date: Wed, 13 May 87 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [RAM: exiting from unwind protects]
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Message-ID: <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 10 May 1987 14:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I find the following pretty persuasive...
I don't. Actually it seems to be mostly irrelevant to the issue at
hand. Here's some commentary on it. Feel free to show this to RAM if
you wish.
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions.
I don't know what debug-return is (presumably something in the Spice
Lisp environment). Unless it's something that bypasses unwind-protect
and deliberately doesn't evaluate the cleanup forms, I don't think it
solves the problem. However, I agree that environment problems can have
environment solutions, and I think the issue is to make sure that the
language doesn't forbid the environment from solving this by trying to
enforce a particular semantics for the pathological construct, instead
of having it be an error.
In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
The second paragraph on p.329 appears to say that it is invalid for a
portable program to do that. What I am arguing for is a similar
restriction on portable programs doing the similar thing with
unwind-protect and throw. So I think this example actually supports my
position.
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
Most of this would be answered by re-reading the relevant proposal to
the cleanup committee (are these archived someplace public?), which
was not written by me. I agree that we need a better-written version
of that proposal that is easier to understand and less ambiguous. The
one I am looking at is
Message-ID: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Edit history: Revision 1 by KMP 02/27/87
My only contribution to the discussion was
in the message <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>.
Here are some relevant excerpts from the referenced proposal:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
...
1. Transfer to a point inside the point to which control
would have transferred.
and what I proposed in answer to this was to do one of three
things in case 1, transfer to a point inside the point to
which control would have transferred.
1. wimp out and say it "is an error"
2. signal an error
3. resume the original throw, just as if the cleanup handler had
exited normally.
I prefer signalling an error, because I firmly believe that the program
is ill-formed.
Note that I have not introduced any new concepts here. I don't think
the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT proposal introduced new
concepts either; it just made explicit reference to concepts that
were already in Common Lisp. The argument that these concepts make
the language definition too complex seems to be an argument that the
language definition should not attempt to define the semantics of throwing
precisely.
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
Last time I read the "error proposal" it included this concept. I don't
think I invented it, I just borrowed it from there while writing up the
discussion of throw vs. unwind-protect. Certainly in the absence of the
error proposal this concept is not introduced into the language, since the
language currently does not contain an IGNORE-ERRORS construct, nor any
other construct that is sensitive to the issue.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
All of point 3 appears to be a misunderstanding of what was being
discussed and proposed. "Transfer to a point inside the point to which
control would have transferred" is irrelevant to "the user types an
interrupt" (which I take to mean something like Maclisp's control-X
and control-G, i.e. abort the program and return to a read-eval-print
loop) since those would be transfers to a point outside of, or equal to,
any throw currently in progress.
If I had ever been screwed by this, I would think differently.
The inside-Symbolics component of this discussion originated with a
customer being screwed by this.
I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form.
Nobody ever proposed anything different as far as I am aware.
Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
The issue is actually what happens you nest throws (throughout this
discussion "throw" has been understood to include all non-local exits,
not only the THROW function). Thus the marker in question is "in throw",
not "in an unwind protect cleanup".
Yes, the dynamic state of a program that is throwing would need to
include an indication of where it was throwing to if we were to adopt
the proposal that misnested throws signal an error or the proposal that
they resume the outer throw. In the "is an error" case, there are no
requirements on the implementation, and the requirement is only that
portable programs cannot assume any particular behavior. However, I
can't imagine an implementation of throw that does -not- remember in its
dynamic state where it's going to throw to when it finishes evaluating
some unwind-protect cleanup forms.
To get back to earth after all this lofty flaming, remember that the
specific case mentioned in the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
proposal was
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and the question is: what does the THROW to BAR do? One possible answer
that many people seemed to favor is it throws to BAR and the throw to
FOO never happens. The answer I prefer is that this is not a valid
Common Lisp program. Does this make the issue clear?
∂12-May-87 2124 Moon@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:24:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138606; Wed 13-May-87 00:23:14 EDT
Date: Wed, 13 May 87 00:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870513002305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Observation: some of the discussion appears to be assuming that
someone is proposing that
(position 3 #2a((0 1 2)(3 4 5))) => (1 0)
As far as I can tell no one is proposing that. My reading of
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
is that it proposes
(position 3 #2a((0 1 2)(3 4 5))) => 3
and the other two options propose that it remains an error.
Vote: I mildly favor SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED as
being the least confusing to users, although either of the other two
proposals would be okay with me: if there is strong support for them,
I won't expend energy resisting it.
∂13-May-87 0012 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870513031041.0.KMP@TSUKUBA.SCRC.Symbolics.COM>
While I'm sympathetic to this proposal in some form, I can't support
it as currently drafted.
My main problem is that it tries to clarify too many things. The question of
what is a function is logically distinct from that of what may go in the
function cell. I am very excited about clarifying the type issues, but very
nervous about changing what can go in the function cell.
Here are my notes on the proposal...
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
* "behavior" is spelled "behvior" in one place.
* I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
* Items 4 & 5 are a major incompatibility that I would like to see proposed
and discussed separately so as not to bog down the type issues which this
proposal should be about. Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
* The adoption cost does not mention STEP, TRACE, and ED. I think it should.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Please don't let these comments get you down. It's clear that a lot of work
has gone into this and I'm hopeful that it will be resolved successfully.
I just want to keep the decision process as unencumbered as possible and
right now it's just too hard for me to reason clearly about the overall
impact of such a sweeping proposal.
-kmp
∂13-May-87 0914 RPG FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
KMP wonders
`` I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.''
The suggestion is on the same pages that allows the following two to
differ:
(let ((x '(or to-be (not to-be))))
(assert `(is-a question ,x)))
``To be or not to be: That is the question.''
KMP's third sentence is the answer: FUNCTION is a type name symbol
that corresponds to no type, and therefore (typep x 'function) is
not defined. This is what this proposal attempts to remedy.
However, to be slightly more serious, I am disturbed to always read
that Common Lisp must do this, that, or the other thing because otherwise
the effort to keep Macsyma up to date will suffer, or that the reason that
some feature must continue to exist is because it is reflected in
Macsyma usage. I like Macsyma as well as the next guy, but not enough to
kill a language to keep its code legal.
-rpg-
∂13-May-87 1133 @ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM FUNCTION-TYPE, archives, and Macsyma
Received: from [192.10.41.45] by SAIL.STANFORD.EDU with TCP; 13 May 87 11:33:01 PDT
Date: Wed, 13 May 87 14:23 EDT
From: KMP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: FUNCTION-TYPE, archives, and Macsyma
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870513142303.6.FILE-SERVER@ALLEGHENY.SCRC.Symbolics.COM>
I spent well over a year converting Macsyma to what I believe is a good
faith reading of CLtL. At the outset, I was as tired as anyone of its
odd little needs that were unwritten parts of various languages and that
had to be supported only out of fear of breaking Macsyma.
I am trying to invoke no such fear now. Indeed, I don't even work for the
Macsyma project any more. I am sure that those who do work for it are
willing to do reasonable work to upgrade Macsyma into the next generation
Lisp.
However, those people (whoever they may be when it finally happens; my
grandchildren, I fear) will need to be able to adequately estimae the
impact of the various changes which we have made. And we ourselves must
adequately estimate the impact so that we can know how much work we are
asking people to absorb.
I said several times in my message that I might be willing to go along
with this change. I am not trying to "kill a language" as you put it.
I just want us to be honest. And when I read the text in this proposal
that said "... attempts to minimize the impact on user code ... the
only impact should be a change in the operation of certain type predicates
... relatively easy to find and fix" I knew we were not being honest.
The changes we're proposing may be good ones. They will not all be easy
to find and fix.
I do think that the part which simply involves types is fairly
non-controversial. I would like to see it separated so we can agree that
it is and leave a smaller issue to worry about.
∂13-May-87 1626 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE and Archives
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 16:25:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139430; Wed 13-May-87 19:24:13 EDT
Date: Wed, 13 May 87 19:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 May 87 12:14 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870513192404.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 May 87 0914 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
[Second part deleted]
This is very useful, but if this was in answer to my question of yesterday
about archiving, I was actually asking a different question. I was wondering
if the current versions of the various proposals are archived somewhere,
such that one could retrieve a single proposal without first wading through
a bunch of mail. This might be a directory with each proposal in a separate
file, for example.
∂13-May-87 2121 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87 21:21:16 PDT
Received: by navajo.stanford.edu; Wed, 13 May 87 21:18:45 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01380; Wed, 13 May 87 20:01:41 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03441; Wed, 13 May 87 20:03:04 PDT
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705140303.AA03441@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 13 May 87 00:02 EDT <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
Subject: looping in unwind-protect cleanups
I tend to agree with you that looping caused by UWP cleanup forms throwing
back through the same cleanup forms is a serious error; and that this
situation not only ought to be "signalled" as an error, but also ought to
be recuperable (from the debugger, I suppose). However, one or two loose
ends need to be cleared up. You mention the example from the original
proposal:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs. The "serious error"
mentioned above is a dynamic condition, which could be caused by other
programs that are not so clearly analyzable. For example, consider just
removing the (THROW 'BAR 4) out of the lexical context:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(DO-A-BIT-OF-WORK)
(PRINT 'XXX))))
(DEFUN DO-A-BIT-OF-WORK ()
(UNLESS (WINNINGP)
(THROW 'BAR 4)))
I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
How about this characterization of the problem: for a given process, the
unwind-protect cleanup forms should be viewed as non-reentrant code. An
attempt to execute such code reentrantly will signal an error, which will
probably enter the debugger (and entering the debugger won't, by itself,
cause another throw, so there is no fear of infinite looping from this
step). In such a case, the user should have the choice of continuing with
the re-entrant invocation, or of doing an "abort" which skips doing the
signalled UWP frame's cleanups. In the first case, he may want to "try
again" at the cleanups, because it just might be that they were entered
"re-entrantly" only because he interrupted in the middle of some cleanups,
and then asked the debugger to "abort to toplevel"; or maybe entering the
"embrace" depends on some global data which he has just "fixed". In the
second case, he may recognize the "deadly embrace" as hopeless, and simply
wish to punt out of it.
There is some concern about "hairing up" the UWP/THROW mechanisms. I
don't believe that this approach, or *** ones like it *** (which were
alluded to in previous messages) is really all that complex.
Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock
(possibly a per-process lock) that is acquired upon entry [and
released upon exit?]. Failure to acquire the lock signals the
re-entrancy error. The acquisition/release time could hardly
be more than a few memory cycles time, and hence won't be a serious
slowdown for THROWing.
(2) The low-level part of THROW would admit a "skip me" argument, so
that it could be told which UWP/CATCH frame to omit the cleanups
on [but not the lock releasings?]. Only one "skip me" is needed,
since nested "deadly embraces" could be undone one step at a time.
[In fact there really only could be one frame to "skip" -- the one
whose lock is already tied up.]
I don't mean to imply that this is the only, or the best, or even the
clearest implementation of such an idea; but I claim that non-re-entrancy
isn't all that deep a concept here. It's more to the point than saying
"non-interruptible" (which is wrong); and more succinct than some other
characterizations of how one might detect the "deadly embrace".
-- JonL --
∂13-May-87 2158 Moon@STONY-BROOK.SCRC.Symbolics.COM looping in unwind-protect cleanups
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 21:58:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139634; Thu 14-May-87 00:57:23 EDT
Date: Thu, 14 May 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8705140303.AA03441@bhopal.edsel.uucp>
Message-ID: <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs.
I didn't mean to imply that.
...I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
Sure. If you give me a few hours, I will mail you examples of programs
in Common Lisp, Ada, and Basic the determination of whose validity in
their respective languages is equivalent to the halting problem. The
basic plan is to write a program where it cannot be mechanically proven
whether an array subscript is out of bounds.
....Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock ....
This is rather overcomplicated, so let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
1. Every catch (including ones generated internally by tagbody and block
when nonlocal exits via go, return, or return-from are happening) contains
a validity bit, which is initially 1.
2. When throw plans to throw past a catch, it sets its validity bit to 0.
This happens after throw finds the target catch (since Common Lisp says if
there is no matching catch, the error is signalled in the dynamic environment
of the throw), and before throw starts removing state from the stack and
evaluating cleanup forms. Here throw includes nonlocal go, return, and
return-from along with certain debugger commands.
3. An attempt to throw to a catch whose validity bit is 0 signals an error
that isn't caught by IGNORE-ERRORS.
4. The error in 3 is implemented by the Common Lisp function BREAK.
5. When throw evaluates an unwind-protect cleanup form, it first removes
it from the list of such forms, so that if you throw again it won't be
evaluated again. (I'm pretty sure that a close reading of CLtL shows
that this is required.)
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
∂14-May-87 1039 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 10:39:24 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 10:36:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA03537; Thu, 14 May 87 10:23:10 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03960; Thu, 14 May 87 10:24:36 PDT
Date: Thu, 14 May 87 10:24:36 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705141724.AA03960@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 14 May 87 00:57 EDT <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
Re: . . . let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
. . .
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
A lock is effectively 1 bit per catch, and by storeing it in the catch
frame, it is process-specific; lock-acquisition would be done in THROW,
and is very low overhead. I suspect these two proposed implementations
are isomorphic at a fundamental level, with your "validity bit" replaceing
my "lock".
The only thing that seems a bit peculiar in your review of the new Symbolics
code is that the error signalled by "failure to acquire the lock" has to be
treated specially (not caught by IGNORE-ERRORS, goes directly to BREAK,
"does not pass GO, lands in jail", whatever). Maybe that is the reason RAM
and some others were so upset by the original proposal. I think I see the
point of the special handling; but I don't like the singularity.
-- JonL --
∂14-May-87 1046 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:45:08 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140100; Thu 14-May-87 13:43:48 EDT
Date: Thu, 14 May 87 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134332.1.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-SYMBOL:NO, but I have the following comments:
* Please change the reference to filename "nil" to filename "NIL"
since (STRING NIL) returns "NIL" and not "nil". This is a minor
point, but I think worth doing.
* Note that the biggest impact of this change on users is that
they will not be able to say (LOAD'FOO) which they commonly type
interactively to mean (LOAD "FOO"). One advantage, of course, is
that in case-sensitive file systems, people won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not
found. Still, I think the fact that we're going to make it an
error for people to type (LOAD 'FOO) is worth documenting as part
of the cost of this proposal so that no one ends up surprised.
∂14-May-87 1051 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:50:32 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140111; Thu 14-May-87 13:49:01 EDT
Date: Thu, 14 May 87 13:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134846.2.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-STREAM:FILES-ONLY.
Since string-streams are non-file streams that CL programmers
will be familiar with, it might be worth mentioning them explicitly
in the proposal as an example of something for which the indicated
functions do not have to work.
∂15-May-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87 21:44:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141562; Sat 16-May-87 00:44:03 EDT
Date: Sat, 16 May 87 00:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>,
<870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870428-220403-2039@Xerox>,
<870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<192793.870429.JAR@AI.AI.MIT.EDU>,
<8704292330.AA13102@bhopal.edsel.com>,
<870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<193127.870429.JAR@AI.AI.MIT.EDU>,
<8704300644.AA13625@bhopal.edsel.com>,
<8704302311.AA01123@bhopal.edsel.com>,
<193809.870430.JAR@AI.AI.MIT.EDU>,
<8705012012.AA00639@bhopal.edsel.uucp>,
<FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>,
<194629.870502.JAR@AI.AI.MIT.EDU>,
<FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Message-ID: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I finally found the time to read this huge pile of mail carefully and think
clearly about it. Here's my considered opinion, but before telling you
which proposal I support I'd like to clear away some underbrush. I
apologize for the 200 line length, but I can't make all the concepts
unambiguously clear with a briefer speech.
We speak of cells, which are conceptual locations that remember a value and
can be read and written. Sometimes these conceptual locations are
implemented by actual memory locations, and sometimes they aren't, but
that's an implementation detail and is irrelevant here. (Sometimes these
are called variables, but other times the word "variable" means something
else, so for the sake of clarity I'm not going to use the word "variable".)
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
Right now, Common Lisp has two kinds of binding: Lexical binding creates a
new local cell. Special binding saves the value of a global cell, gives it
a new value during the extent of the binding, and later restores the old
value. We know that special binding saves and restores because of what
other functions see when they read the cell. Please don't get confused
with issues of shallow-bound versus deep-bound implementation, which are
irrelevant here: I said cells are not the same thing as memory locations.
Note that I am carefully using different words for the two kinds of cells
from the words for the two kinds of binding; lack of differentiation here
has led to a lot of confusion, I think.
Right now, Common Lisp has a fairly complicated set of rules for how to
determine what cell is referenced when a program mentions a variable name.
(When I say "lexically free", I mean outside of all bindings of that name,
regardless of whether those bindings are special or lexical.)
1. If the reference is lexically free, use the global cell.
2. Otherwise, in the absence of a SPECIAL declaration use the cell that
was affected by the innermost binding; if that binding was special,
use the global cell; if it was lexical, use the local cell created
by that binding.
3. Otherwise, the SPECIAL declaration forces use of the global cell.
We certainly do not want to introduce a third kind of cell, because that
would lead to a great deal of confusion. Nor do we want to introduce a
third kind of binding. What we -are- trying to accomplish is to make the
primitive concepts orthogonally available. An example of a problem we have
right now that needs to be fixed is that there is no way to say that a name
is not misspelled without simultaneously saying that bindings of that name
should be special rather than lexical. These concepts should be available
as separate constructs.
There are four things that we would like to be able to proclaim about
a variable name (aside from TYPE):
- the default kind of binding if no declaration specifies which kind
- the name is not misspelled so don't warn about free references
- it is illegal to specially bind the global cell, because it is
a constant or because we want to optimize the performance of a
deep-binding implementation
- it is illegal to store into the global cell, because it is a constant
It is already possible in Common Lisp to proclaim all four of these things,
but some of them are mixed up with other concepts and not separately
available. Let's pick names for the four kinds of proclamations, and let's
also agree that any proclamation serves the "not misspelled" purpose. Let's
further agree that these four proclamations are mutually exclusive.
LEXICAL -- does nothing other than "not misspelled"
SPECIAL -- changes the default kind of binding from lexical to special
GLOBAL -- makes it illegal to specially bind the global cell
CONSTANT -- makes it illegal to store into the global cell
CONSTANT implies GLOBAL because special-binding is storing
SPECIAL exists now. LEXICAL is Rees's proposal. CONSTANT exists now
but only buried inside the DEFCONSTANT macro. GLOBAL exists now but
only when implied by DEFCONSTANT. I propose to make CONSTANT and
GLOBAL explicitly available.
It appears to be appropriate to make CONSTANT and GLOBAL proclamations
change the default kind of binding to "illegal", rather than leaving
it lexical.
Now we have to ask what these proclamations mean as declarations.
Let us agree that they have the same scoping rules as the SPECIAL
declaration, i.e. they can be attached to a binding and they can
also be wrapped around references, which they pervasively affect
until shadowed by the next declaration or binding.
LEXICAL attached to a binding forces the binding to be lexical even
if there is a SPECIAL, GLOBAL, or CONSTANT proclamation. LEXICAL
shadows the effect of a special binding on references; therefore we
must add another rule to the "complicated set":
4. Otherwise, a LEXICAL declaration forces use of the local cell
created by the innermost lexical binding of the name, or if there
is none, use of the global cell.
SPECIAL means the same as it has always meant in Common Lisp.
GLOBAL or CONSTANT attached to a binding makes the binding illegal.
GLOBAL or CONSTANT affects a reference by forcing it to use the global
cell, thus rule 3 in the "complicated set" must be modified to treat GLOBAL
and CONSTANT the same as SPECIAL. We could also just make GLOBAL and
CONSTANT illegal as declarations. Another idea would be to make CONSTANT
as a declaration allow you to create a new lexical constant. I'm going to
take the path of least addition to the language and make them illegal.
Note that PROCLAIM-LEXICAL:RESTRICTED conflates LEXICAL and GLOBAL, which
seems undesirable to me. We want to make each primitive concept separately
available.
Okay, so which proposal do I support? Well, I support a slight modification
of PROCLAIM-LEXICAL:GENERAL, which I will now explicate (text mostly
copied from Rees):
Proposal (PROCLAIM-LEXICAL:GENERAL+GLOBAL):
Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT, which
are mutually exclusive with the SPECIAL declaration specifier. All four
may be used as proclamations; only SPECIAL and LEXICAL may be used as
declarations.
A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
CONSTANT. A name is said to be unproclaimed if it has not been
proclaimed to be any of these four.
A free reference or assignment to a name is an error if it is
unproclaimed and undeclared.
A LAMBDA-binding in the absence of a declaration or proclamation binds
the lexical variable.
SPECIAL proclamations and declarations behave as defined in CLtL.
LEXICAL proclamations have no effect other than to make the name
cease to be unproclaimed. LEXICAL declarations shadow all enclosing
declarations and proclamation of any of these four types. LEXICAL
declarations have the same scoping rules as SPECIAL declarations.
GLOBAL proclamations make it an error to bind the name.
CONSTANT proclamations make it an error to bind the name and an
error to assign to the name.
DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
All keyword symbols are automatically proclaimed CONSTANT.
A free reference or assignment accesses the same value regardless
of the declaration or proclamation. This is called the global value.
SPECIAL binding alters the global value within its extent.
(Multiple process and multiple processor systems will have to make
their own definitions of the extent of a SPECIAL binding, as noted
on p.38 of CLtL--this proposal is not a proposal to standardize that.)
The preceding paragraph should be understood carefully. There is only
one global value for a name and it is used by all free references, all
free assignments, and all SPECIAL bindings.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Note that the second element of the list is different from
the value, 2, it would have in PROCLAIM-LEXICAL:GENERAL.
That is because the special binding of y changes the global
value to 4, and the declared-lexical reference to y accesses
the global value, since there is no surrounding lexical binding.
Cost of adopting change:
I believe this is the same as current practice as specified by CLtL,
except that all of the primitive concepts have been made visible instead
of being hidden inside other concepts. Compilers and interpreters
will need to support LEXICAL as a declaration.
Referencing or assigning to an unproclaimed and undeclared name
"is an error", not "signals an error", which allows but does not
require an implementation to issue a warning. This is a change from
current language but does not mandate a change from current practice.
Benefits:
LEXICAL proclamation enhances compatibility with Scheme.
GLOBAL proclamation allows more efficient deep-bound implementations
and enhances compatibility with Interlisp and VMLISP.
Cost of converting existing code:
None, it's upward compatible.
Aesthetics:
The "insidious and disgusting aspect" doesn't get any worse. Making
primitive concepts explicitly available can only enhance aesthetics.
Discussion:
Let's hear it!
∂16-May-87 0302 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 May 87 03:02:07 PDT
Received: by navajo.stanford.edu; Sat, 16 May 87 02:58:25 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA10964; Sat, 16 May 87 01:33:58 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA09180; Sat, 16 May 87 01:35:27 PDT
Date: Sat, 16 May 87 01:35:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705160835.AA09180@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 16 May 87 00:43 EDT <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
Your summary of the "proclamation" issue is excellent. It delineates all
the separate issues very well, and also it incorporates all the points I
have made in previous notes about these matters. So I for one would be
quite happy to see your revised proposal accepted.
-- JonL --
∂17-May-87 1447 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 14:47:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 17:46:49-EDT
Date: Sun, 17 May 1987 17:46 EDT
Message-ID: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 16 May 1987 00:43-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
It seems to me that we want to allow a variable to be re-proclaimed for
two reasons: to correct proclmations issued in error by the user,
without having to kill off the Lisp and start over, and to make it
easier to merge programs written by two different programmers. (The
latter reason may be bogus -- these guys shouldn't be in the same
package anyway -- but there are times when a quick-and-dirty fix is
extremely handy.) On that other hand, we want the compiler to be able
to wire certain things in tight as a result of these proclamations, so
we need to make clear that if you proclaim something to be GLOBAL,
compile some code, then proclaim it to be SPECIAL and then compile some
more code the rebinds this variable, you may not get what you expect.
Same with unconstantifying a constant.
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
-- Scott
∂17-May-87 1931 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 1987 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
In-reply-to: Msg of 13 May 1987 03:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>.
My main problem is that it tries to clarify too many things.
I agree with Moon that Compile can be split out of this proposal and
dealt with separately. However, I feel that the other issues really
have to be dealt with all at once. The issue of what constitutes the
FUNCTION type and whether function definitions have to be functions in
whatever sense we define are closely interconnected. We'll ahve to
solve the latter issue sooner or later, so let's try to do it now.
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
No problem with eliminating any mention of this. It was just a "for
instance" anyway.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
I disagree with this use of "description", but there's no point in
arguing epistemology here. I'll change the wording.
Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
I don't understand this. If your code expects to put random symbols and
lambda lists into function cells and to get them back later, unchanged,
this is not portable Common Lisp. At least, the manual is so vague in
this area that you'd better not count on anything of this sort being
portable. PCL was storing symbols in symbol-function cells for awhile,
but this broke lots of implementations and they finally gave up on this.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
I know of several Common Lisps in which this is not the status quo. So
either way we clarify this, it is an incompatible change for someone. I
hate to see us take a step backwards here, just to make Macsyma more
portable than it currently is.
I agree that we should make a bit more of this issue in the "conversion
costs" section -- truth in advertising -- but I think that saying that a
function definition must be a function is an important part of the
rationalization we are trying to achieve.
Would it make life any easier for Macsyma (and other programs with this
same problem, if any exist) if we were to add a function that extracts
the lambda expression from a function if the function is uncompiled and
is not a closure (in the stronger sense mentioned above)? In some
implementations this might be EQ or at least EQUAL to the original
Lambda, but in others it might have been macro-expanded or altered in
some way that preserves its essential behavior. We could call the
function EXTRACT-LAMBDA-EXPRESSION or something like that.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
How about if we just adopt your earlier proposal: if the function is
already compiled, COMPILE is a no-op that returns the NAME.
* The adoption cost does not mention STEP, TRACE, and ED. I think
it should.
OK.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
OK.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Well, as I said, such code is currently not portable because nothing in
the book unambiguously requires that symbols and lambda expressions be
put into the SYMBOL-FUNCTION cell unchanged (or that such changes be
undone upon retrieval), and because many implementations currently do
not do this. So there's a cost either way we clarify this. Doing it
the way you suggest tends to put the burden on implementors rather than
on the maintainers of old code, but I still think it is a step
backwards.
-- Scott
∂17-May-87 1944 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE and Archives
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:42:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:42:14-EDT
Date: Sun, 17 May 1987 22:42 EDT
Message-ID: <FAHLMAN.12303233875.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE and Archives
In-reply-to: Msg of 13 May 1987 12:14-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
In reply to: Dick Gabriel <RPG at SAIL.STANFORD.EDU>.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
I assume that the "stronger proposal" you favor would require FUNCALL,
APPLY, and friends to accept only true functions.
I would go along with putting both options into the proposal we send to
X3J13 and let them vote on it. My guess is that the conservatives would
prevail, but I personally would favor the "stronger proposal". (That's
easy for me, because I have relatively little code to maintain.) It
might be worth a try -- maybe truth and beauty would win.
However, there's a chance that if we put forward two options, the whole
thing will bog down for a while. I wonder if it is worth the risk of
added delay.
-- Scott
∂18-May-87 1344 gls@Think.COM Issue: PROCLAIM-LEXICAL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87 13:44:21 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 18 May 87 16:46:47 EDT
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870518164427.1.GLS@BOETHIUS.THINK.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
In the terminology of CLTL chapter 3, both kinds of cell have
indefinite extent (but the bindings of a global cell have dynamic
extent). The *names* used to refer to these cells have lexical
and <???> scope, respectively.
If this bit of language were to be cleaned up, I would favor something
like Moon's proposal.
--Guy
∂18-May-87 1529 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 15:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142936; Mon 18-May-87 18:28:46 EDT
Date: Mon, 18 May 87 18:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870518164427.1.GLS@BOETHIUS.THINK.COM>
Message-ID: <870518182849.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
Quite right. I must have meant to say "scope", but spazzed.
∂19-May-87 1316 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-NEGATIVE-PARAMETERS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 13:16:02 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143993; Tue 19-May-87 16:15:07 EDT
Date: Tue, 19 May 87 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-NEGATIVE-PARAMETERS
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Message-ID: <870519161434.8.KMP@TSUKUBA.SCRC.Symbolics.COM>
[Removed Berman, Common-Lisp; added CL-Cleanup]
Date: Tue, 19 May 1987 15:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: 19 May 1987 14:38-EDT
From: Richard Berman <berman at vaxa.isi.edu>
... do you know what this should do?
(FORMAT NIL "~-1%")
... there seem to be a number of places in the format directives where
negative numbers would make no sense. I don't think that all of these
are explicitly flagged. This should probably be fixed up in the
standard, but until then it seems reasonable to assume non-negative
integers unless there's some obvious meaning for the negative case.
This would be a reasonable topic for us to address in CL-Cleanup.
I agree that a reasonable approach for the interim, and in fact in the
next edition of the manual, is to say that format parameters are assumed
to be non-negative integers except as specifically stated. Of course, we'll
need to specify clearly whether signalling an error or assuming 0 or whatever
is the right thing otherwise, and that should perhaps be done by someone who
has surveyed all the ops to determine the likely impact on typical code of
assuming 0, etc.
Cases where some implementations signal an error and others quietly ignore
the error are what drive developers of portable code nuts.
By the way, I note that this case is most important where the user has
written ~V%, since it's not statically detectable in that case that a problem
has arisen.
Obviously, someone should write this up as a formal proposal. I've picked
the issue name FORMAT-NEGATIVE-PARAMETERS above and this message can be used
to seed the proposal when someone has time to write it.
∂19-May-87 1739 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 17:39:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144321; Tue 19-May-87 20:38:25 EDT
Date: Tue, 19 May 87 20:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Message-ID: <870519203829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 17 May 1987 17:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think I forgot to answer this, but if you're seeing it twice, I apologize.
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal
Thanks.
except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC
CONSTANT, you mean.
can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
I think this is an environment issue rather than a language issue.
....
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
that Lisp.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.
Actually I just copied that from Rees.
The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1801 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:01:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:00:27-EDT
Date: Tue, 19 May 1987 21:00 EDT
Message-ID: <FAHLMAN.12303739600.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 19 May 1987 20:38-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree here, more or less. I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers. Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them. So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)
this issue doesn't affect portable
programs, but that's not the only concern we should deal with. I would
like to see
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1812 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:12:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:11:08-EDT
Date: Tue, 19 May 1987 21:10 EDT
Message-ID: <FAHLMAN.12303741560.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
Sorry, I hit the wrong key and shot that last message off before I was
done editing...
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users. Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our ONLY concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any legal Common Lisp, and this is one of those
things. So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.
So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.
-- Scott
∂26-May-87 1431 Masinter.pa@Xerox.COM administrative
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 May 87 14:31:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 MAY 87 14:26:31 PDT
Date: 26 May 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: administrative
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870526-142631-1697@Xerox>
I've gotten way behind the last couple of weeks on my mail.
I hope we are not too late to mail out the proposals we have ready for
voting at X3J13. I'll try to get a summary out this week and revised
versions.
I have a separate file of mail on each proposal, where the latest
version of each proposal is generally a recent message. However, these
are not on an externally available file server. I started to try to keep
the latest version of each proposal in a separate file on a public
server, but it was a lot of work with no percieved benefit.
Right now, I'll just offer the service that if anyone needs the latest
version of something , send me a personal message and I will mail it
out. (This may seem inconsistent with my being behind in my mail, but
personal mail gets priority.)
If anyone has any revised versions of any of the open proposals they
want to submit for consideration at the next X3J13 meeting, this is the
week to get them in.
∂28-May-87 2233 JAR,KMP@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 May 87 22:32:46 PDT
Date: Fri, 29 May 87 01:34:10 EDT
From: JAR, KMP@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
Subject: Issue: PROCLAIM-LEXICAL
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <206630.870529.JAR@AI.AI.MIT.EDU>
We feel that the exposition preceding Moon's proposal contains some
assumptions which lead him to conclusions with which we're somewhat
uncomfortable.
Although the proposal is coherent and we don't think it's technically
unworkable, we're not really happy with the conceptual model of
special binding which it seems to presuppose.
Apparently, I (JAR) have been hacking denotational semantics so long
that the way that Lisp hackers think is now completely foreign
to me. Moon's notion of a "cell" feels very unnatural, for example.
Were I to write a Common Lisp EVAL in a less complicated language,
e.g. lambda calculus, Pascal, or Scheme, I would start as follows:
(defun eval (exp lexical-env dynamic-env store cont)
(cond ((symbolp exp)
...)
...))
In this notation, a DYNAMIC-ENV maps names to locations, and a STORE
(British word for memory) maps locations to values. This makes clear the
exact manner in which the "meaning" of a variable depends on the context
(dynamic, lexical, and prior side-effects) in which it occurs. It looks
like Moon's notion of a "cell" bundles these two mappings in some way,
but it's not completely clear how. It would be interesting to see how
Moon would write EVAL (using UNWIND-PROTECT perhaps?) in a language that
had no side effects or dynamic binding.
The intent here is not to convince anyone that some particular
model is right or wrong, but to point out that there's more than one
valid way of modeling all this. Moon's proposal follows neatly from
the exposition which precedes it, but since we're not happy with the
exposition, it's not surprising that we're not happy with the
proposal.
One particular point of contention: we're uneasy about Moon's suggestion
that binding a special variable can affect the evaluation of a lexical
variable. This is an example of how a bias toward a shallow-binding model
shows through.
These remarks are too brief and we expect to have more to say on
this later, but since Larry's probably making up a status report for
presentation to X3J13, and since the comments on Moon's proposal have
thus far been non-critical, we wanted to get it into the record that
we think there's more work to be done here.
∂29-May-87 2113 Masinter.pa@Xerox.COM barrage of mail coming
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:13:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:17 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
Subject: barrage of mail coming
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-211317-1248@Xerox>
Stay tuned for a barrage of mail; I've been trying to get the open
proposals into a form that we can ship. I will send out new copies of
several proposals where I've made minor (or in a few cases major) edits
to incorporate comments on this list.
You will get:
Revised versions of many of the proposals (at least up thru
PATHNAME-SYMBOL today)
A revised status report (ditto)
A ***BALLOT***. Most of the ballot items are of the form:
[ ] Release as is [ ] Comments follow in mail to cl-cleanup.
Most of this is just double checking to make sure that the silent
members of the committee really agree even if they haven't responded.
∂29-May-87 2114 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:14:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:54 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
Message-ID: <870529-211354-1250@Xerox>
Status: Minor edits for presentation. No disagreement in committee.
Ready for release? (use ballot).
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: Steele p.297
Category: Clarification
Edit history: Revision 1 by SEF, 18-Apr-87 (from Steele's list)
Revision 2 by Masinter (minor)
Problem Description:
The interaction of Adjust-Array and displacement is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced to B before
the Adjust-Array call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :initial-element. The use of :initial-contents
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before the call, and is displaced to C after the
call. As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C). If
:displaced-index-offset is not specified in the Adjust-Array call, it
defaults to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element. However, the use of
:initial-contents causes all old contents to be discarded.
Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y. This means that an implementation
may not collapse the chain to make X refer to Z directly and forget that
the chain of reference passes through array Y. (Cacheing techniques are
of course permitted, as long as they preserve the semantics specified
here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here. Others
may do something random. [See discussion below.]
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
Discussed long ago on the Common Lisp mailing list. This proposal
attempts to capture the overall consensus that emerged at that time.
Moon: We [Symbolics] implement what is proposed, except for
(4) A is displaced to B before the call, but not displaced
afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional
elements
of A are taken from the :initial-element.
We never copy the contents of B in this case; all elements are taken
from the :initial-element.
Either behavior seems equally justifiable to me. One could say
"adjust-array never stores into the array if it ends up displaced" or
"adjust-array only preserves the elements of non-displaced arrays." I
have no information as to whether it matters to users.
∂29-May-87 2116 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:16:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:15:53 PDT
Date: 29 May 87 21:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211553-1257@Xerox>
Status: I worked over the wording on this one a little. Ready for
release?
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Revision 2 by Masinter
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
Rationale:
This clarification follows the intent of the original Common Lisp
designers.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
Benefits:
This clarification makes the semantics of an important primitive more
well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
The cleanup committee supports this clarification.
∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:17:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:05 PDT
Date: 29 May 87 21:16 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 2)
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-211705-1259@Xerox>
Status: I merged in various comments. Ready for release? [use ballot]
Issue: DO-SYMBOLS-DUPLICATES
References: Do-Symbols, Page 187
Category: Clarification
Edit history: Revision 1 by SEF 17-Apr-87
Version 2 by Masinter, add other options
Problem Description:
CLtL specifies that Do-Symbols executes the body once for each symbol
accessible in the package. It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed). It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates. For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications. Users who really
want the duplicates to be removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Adoption Cost:
None. Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.
Benefits:
Clarification of a situation that is currently ambiguous.
Conversion Cost:
Users who have been assuming that DO-SYMBOLS eliminates duplications
will have to be modified, but such code would run on few existing Common
Lisp systems.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a
clear case of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.
The need for do-symbols to be efficient is questionable, however; for
many applications (e.g., global package manipulation), duplicate values
would create havoc.
For some implementations, the performance penalty would be well over
a factor of two.
Proposal: DO-SYMBOLS-DUPLICATES:ADD-KEYWORDS
Add a keyword argument to the DO-SYMBOLS macro :ALLOW-DUPLICATES (default
value T) which would make the choice explicit. E.g.,
(DO-SYMBOLS (SYMBOL (FIND-PACKAGE "FRED") NIL
:ALLOW-DUPLICATES T
:EXTERNAL-ONLY NIL)
...)
Rationale:
This proposal allows applications which need to be careful the
opportunity to do so.
Current Practice:
No current implementation has this feature.
Adoption Cost:
Implementations which currently can produce duplicates would have
to keep track of symbols which were previously in the macro expansion.
Benefits:
The default case would run efficiently, and yet users could also have
code that guaranteed that there were no duplicates.
Conversion Cost:
Users who have been assuming that DO-SYMBOLS eliminates duplications
would only have to add a :ALLOW-DUPLICATES T.
Aesthetics:
This proposal makes the language slightly more complex, but allows
for both efficiency and accuracy.
Discussion:
Should the default value of :allow-duplicates be nil instead?
∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:18:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:40 PDT
Date: 29 May 87 21:17 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 5)
Message-ID: <870529-211740-1263@Xerox>
Status: Ready for release? [Use ballot]
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Revision 4 by SEF 11-Apr-87
Revision 5 by SEF 11-Apr-87
Problem Description:
Do Flet, Labels, Defmacro, Macrolet, Defsetf, Define-Setf-Method, and
Deftype have an implicit block around their bodies like the body of a
Defun? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with Defun.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by Flet and Labels and each macro created by
Defmacro and Macrolet has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in Defsetf, Define-Setf-Method, and
Deftype is surrounded by a block with the same name as the accessor
or type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
There are two coherent alternatives to the proposal above:
The first would be to keep the implicit block in Defun, and to clearly
state that the other forms do not create implicit blocks. This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.
The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms. There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change. Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature. Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations. The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.
∂29-May-87 2119 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:19:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:18:40 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211840-1264@Xerox>
Did I miss this?
----- Begin Forwarded Messages -----
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 29 APR 87 18:52:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127874; Wed
29-Apr-87 21:51:16 EDT
Date: Wed, 29 Apr 87 21:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: FORMAT-OP-C (Version 2)
To: Masinter.pa
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870429-184508-3208@Xerox>
Message-ID: <870429215106.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Sounds right. I'll edit that in to Version 3 with Pavel's
correction when the comments subside.
----- End Forwarded Messages -----
∂29-May-87 2119 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:19:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:04 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 4)
Message-ID: <870529-211904-1265@Xerox>
Status: Ready to release? [Use ballot]
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
Even though there is a predicate FUNCTIONP, it is not synonomous to the
use
of the type FUNCTION; the FUNCTION type cannot be used for
discrimination.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments should be to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions, where a symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the the behavior of Common
Lisp; the descriptions must be changed to accommodate the new definition
of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE is changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression" the behavior of COMPILE should be described as "a
definition from which the implementation is able to reconstruct a
lambda-expression".
Rationale:
This change gives a clean, useful definition to the FUNCTION data type
in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
The definition of FUNCTIONP varies widely between Common Lisp
implementations. No current Common Lisp implementation has exactly the
semantics described here, however.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. Some implementations already always store special
types in function cells, but others, which currently store and return
LAMBDA expressions in SYMBOL-FUNCTION, would be required to change the
behavior of (interpreted FUNCTION).
Some implementations will have to modify the behavior of COMPILE, STEP,
TRACE and (possibly) ED to deal with non-list values in symbol-function
cells.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. One impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
User code which relies on the fact that in some environments,
SYMBOL-FUNCTION returns a list in a well-known format for functions
defined in the lexical global environment will have to change.
Similarly, some implementations currently allow users to say (SETF #'FOO
'BAR) and then subsequently have a redefinition of BAR affect the
behavior of FOO. This would no longer be allowed, and users of those
implementations would have to change their code. Others with home-grown
steppers, trace and advise facilities which manipulated the contents of
function cells might have additional work to do.
User code which uses COMPILED-FUNCTION-P would no longer be valid or
portable.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was written after a discussion of the conversion
problems that such an incompatible change might entail. Some cleanup
committee members would prefer the stronger proposal.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. Fahlman believes that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
Pitman believes that items 4 and 5 are major incopatibilities, and would
prefer if FUNCTION and SYMBOL-FUNCTION be allowed to return things which
are non-functions if those objects can be coerced to functions, and SETF
of SYMBOL-FUNCTION can accept such a coercible object, and the value
later retrieved will be the given object (not a coerced form of it),
though obviously internally some encapsulation may want to go on for
stock hardware to make function calling fast.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
∂29-May-87 2121 Masinter.pa@Xerox.COM Re: Issue GC-MESSAGES (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:58 PDT
Date: 29 May 87 21:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue GC-MESSAGES (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 23 Apr 87 23:31 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870529-211958-1267@Xerox>
>Date: Thu, 23 Apr 87 23:31 EDT
>From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>This seems a little short-sighted. GC messages aren't necessarily the
>only unsolicited messages. In the example application you gave, there
>is no reason to treat GC messages differently from other messages.
>Also, a simple on/off switch may be a bit too simple. Not all systems
>have windows, but for the ones that do a three-state switch could be
>defined in an implementation-independent way: (1) turn the messages
off,
>(2) put them in the typescript, (3) make them visible to the user in a
>way that doesn't interfere with the typescript. Even some
>teletype-oriented systems are able to implement option 3.
>In some systems it may not be possible to implement this with a
variable,
>since changing the state of the switch may have to communicate with an
>operating system written in some horrible language. The safest thing
would
>be a macro, whose expansion is system-dependent, and within the dynamic
>extent of the macro's body unsolicited messages are controlled.
>I'm not very optimistic about the possibility of standardizing on this
kind
>of environmental issue, but perhaps some very simple facility to
prevent
>messing up of the screen can be agreed on.
I agree that the GC-MESSAGE issue should be somehow merged with a good
way of dealing with all unsolicited messages.
I can think of other alternatives to the solution proposed by David ("a
macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.").
I'd like to see the "current practice" section expanded. I know that
Xerox Common Lisp has no unsolicited GC messages, don't know about
Lucid, Gold Hill, Franz, etc.
Kent, since you apparently know what these other systems do ("Other
systems provide ways of enabling or disabling the messages, or
customizing the message which is typed out." perhaps you could
elaborate.)
∂29-May-87 2121 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:25 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212025-1274@Xerox>
Status: ready for release? [Use ballot]
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: 9-Jan-87, Version 1 by Masinter (from Steele list)
7-Apr-87, merged with other environment argument issues
29-May-87, Version 2 by Masinter, extracted again
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
The language specification should be explicit on the point that
MACROLET, FLET and LABELS can shadow a SETF method; a SETF method
applies only when the global function binding of the name is lexically
visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee supports this change.
∂29-May-87 2122 Masinter.pa@Xerox.COM IGNORE-ERRORS (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:51 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212051-1278@Xerox>
Status: Ready for release? [Use ballot]
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value).
Revision 4 by Masinter 29-May-87 minor formatting
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET (as on p428 of CLtL)
Introduce a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
IGNORE-ERRORS executes the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms).
If an error occurs while executing the forms, however, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns a principal value of NIL.
(The return value convention for any other values besides the principal
return value in the case of an error is expressly left undefined in order
to leave room for the full error proposal to attach a useful meaning.)
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
We believe this is not difficult to implement in any current implementation.
E.g., IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
Masinter wonders why KMP isn't spending more time on the error proposal.
The cleanup committee endorses this extension.
∂29-May-87 2123 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:23:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:22:29 PDT
Date: 29 May 87 21:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212229-1283@Xerox>
Status: I edited this to put some things in different sections
(Aesthetic arguments under aesthetics, cost of converting existing code
into that section) and added some wording to meet Scott's "to prevent
confusion".
Ready for release? [Use ballot]
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument
names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL. That is:
If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY (((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols
arises when the set of non-positional arguments accepted by a function
is
the union of the sets of non-positional arguments accepted by several
other
functions, rather than being enumerated in a single place. In this
case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is
the draft proposal for an object-oriented programming standard (CLOS).
It will
have generic functions that accept non-positional arguments and pass
them on
to one or more applicable methods, with each method defining its own set
of
arguments that it is interested in. If this proposal is not adopted,
either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with
an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.
A second example of a Common Lisp application that requires this
capability
is private communication channels between functions. Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override
some keyword in keyword-value-pairs, since the only way that could
happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user
was
programming explicitly in the FOOLAND package, either of which is an
implicit
admission of willingness to violate FOOLAND's modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding
the impact of the proposal.
Change wording which refers to non-positional arguments as being
introduced
by keyword symbols to simply refer to those arguments being introduced
by
symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
Also, the word "keyword" in the first complete sentence on p.62 would
be changed to "symbol" for similar reasons.
Add extra wording on p.60 to explain that by convention keyword
symbols
are normally used as non-positional argument names, and that all
functions
built into the Common Lisp language follow that convention. A
language
manual might or might not choose to describe the circumstances in
which
it is appropriate not to follow this convention.
Add examples to illustrate this behavior. For example, on p.64 the
following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction
that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword
argument name, but allow all non-NIL symbols. (One Symbolics version
that
was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other
things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
In any case, users who do not want to use the extended functionality
can generally avoid it.
Discussion:
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
Some members of the cleanup committee would just as soon exclude NIL as
a legal keyword-indicator. It might catch some errors, but is possibly
otherwise an odd restriction. Disallowing NIL would reduce the adoption
cost for some implementations.
The cleanup committee supports this change.
∂29-May-87 2124 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:24:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:17 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212317-1288@Xerox>
Status: Ready to release?
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: We believe no existing user code relies on any values.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂29-May-87 2125 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:25:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:41 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212341-1290@Xerox>
Status: Merged comments in. Ready for release? [Use ballot]
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Category: (Incompatible) CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected.
Rationale:
The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a
symbol
here was that it did not have strings at all. However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
One example of the type of bug caused by this occurs when NIL is
erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find
a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file
named
"NIL" on some perhaps unexpected directory.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since
this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that
check the type of this argument, program error checking will be
improved. In dealing with case-sensitive file systems, users won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not found.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings. For example,
some users are used to type interactively (LOAD 'FOO) to mean (LOAD
"FOO").
Aesthetics: Improved by the change.
Discussion:
Some users have reported the "fact" that MERGE-PATHNAMES was in error
because it accepted symbols.
The Cleanup committee supports this change.
∂29-May-87 2127 Masinter.pa@Xerox.COM Status [Part 1]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:27:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:26:19 PDT
Date: 29 May 87 21:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Status [Part 1]
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-212619-1296@Xerox>
I wanted to get this part out; I haven't updated my status file for the
issues beyond PEEK-CHAR-READ-CHAR-ECHO. I will mail a ballot [Part 1]
separately.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
(Standardize interaction of adjust-array and displacement)
Revision 1 by SEF, 18-Apr-87
Comment by Moon 21 Apr 87
Ready for release?
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
(Extend adjust-array so its OK on non-adjustable arrays, just
makes a new array.)
Not ready for release
Submitted by KMP 22-Apr-87
comments from Moon, JonL, SEF generally against current form
AREF-1D (Version 1)
(Add a new function for accessing arrays with row-major-index)
Submitted 22-Apr-87 by KMP
Some discussion, no strong objection
Ready for release?
ASSOC-RASSOC-IF-KEY
(Extend ASSOC-IF, RASSOC-IF, ASSOC-IF-NOT, etc.
to have a :KEY keyword)
Submitted 22-Apr-87 by KMP
COMPILER-WARNING-BREAK (revision 2)
Not released.
Questions on interaction with condition proposal.
Needs volunteer to pursue.
COMPILER-WARNING-STREAM (Revision 3)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Released.
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
DEFVAR-INITIALIZATION (Revision 3)
((DEFVAR var) doesn't initialize)
Released
remailed 7-apr-87
DEFVAR-INIT-TIME (Version 2)
(DEFVAR initializes when evaluated, not later.)
Submitted 23-Apr-87, Version 1 by Pitman
Version 2 29-May-87 by Masinter
Ready for release?
DO-SYMBOLS-DUPLICATES (Version 2)
(can DO-SYMBOLS see the same symbol twice?)
Version 2 by Masinter
Ready for release?
Question "is it really inefficient to require non-duplicates?"
Add duplicates-allowed keyword?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF summarized issues 18-Apr
Decided to separate again into
GET-SETF-METHOD-ENVIRONMENT,
MACRO-FUNCTION-ENVIRONMENT
SPECIAL-FORM-SHADOW
Not released
FLET-IMPLICIT-BLOCK (Version 5)
(do FLETs have implicit named blocks around them?)
Discussion & agreement on cl-cleanup.
ready for release?
FORMAT-ATSIGN-COLON (Version 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-NEGATIVE-PARAMETERS
Not written up yet; mail 19-May by KMP
FORMAT-OP-C (Version 2)
(What does ~C do?)
Needs rewording to say "change CL" rather than "change CLtL"
remove mention of ~Q
Not yet released
FUNCTION-TYPE (Version 4)
(Change definition of FUNCTIONP, function type ...)
By Masinter 29-May-87
Ready for release?
GET-SETF-METHOD-ENVIRONMENT (Version 2)
(Environment argument for GET-SETF-METHOD)
By Masinter 29-May-87
Ready for release?
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
IF-BODY (Version 5)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
Version 5 mailed by KMP , 29-Apr-87
Awaiting a version which KMP and SEF agree
is "fair"
IGNORE-ERRORS (Version 4)
by Masinter 29-May-87
Ready for release?
IMPORT-SETF-SYMBOL-PACKAGE (Version 4)
Version 3 Released
Removed confusing "To further clarify: " sentence
re-release as Version 4
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
by Masinter 29-May-87
Ready for release?
PATHNAME-STREAM (Version 2)
by Masinter 29-May-87
Ready for release?
PATHNAME-SYMBOL (Version 2)
by Masinter 29-May-87
Ready for release?
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
Withdraw?
∂29-May-87 2128 Masinter.pa@Xerox.COM ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:28:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:27:25 PDT
Date: 29 May 87 21:27 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-212725-1304@Xerox>
Please vote on the following issues which are open. "Release" means to
release the document to X3J13 for discussion & voting.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
∂29-May-87 2133 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:33:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:32:30 PDT
Date: 29 May 87 21:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 5)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-213230-1315@Xerox>
Status: ready for re-release. (I almost called this Version 3, but with
the addition of the comments of DRIBBLE it really is different.)
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Revision 4 by Fahlman, incorporate Dribble
Revision 5 by Masinter, 29-May-87
revert to version 3 with comment about Dribble.
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂29-May-87 2214 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 22:14:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:12:59 PDT
Date: 29 May 87 22:12 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-221259-1332@Xerox>
Status: I cannot find any discussion on this topic.
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: GET (SETF), REMPROP, GETF (SETF), REMF, pp. 165-167.
NREVERSE, p. 248.
DELETE, DELETE-IF, DELETE-IF-NOT, DELETE-DUPLICATES,
NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, pp. 254-256.
NCONC, NRECONC, p. 269.
NBUTLAST, p. 271.
NSUBST, NSUBST-IF, NSUBST-IF-NOT, p. 274.
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR, p. 276-279.
Edit history: Version 1 by DLA@SCRC-STONY-BROOK.SCRC.Symbolics.COM
Problem Description:
Currently, the exact nature of the list modification
performed by REMF and REMPROP is not specified. Conversation on the
Common-Lisp mailing list has made it clear that this situation is not
good. The list modification allowed should either be specified, or
explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
This argument can be made for most of the destructive functions
specified above, and possibly others, so they are included as
references.
Category: clarification
Proposal: REMF-DESTRUCTION-UNSPECIFIED:DONT-SPECIFY
I propose that CLtL's documentation on each of the above functions
include a statement such as the following: "This function performs a
modification to the top-level [list] structure of its argument(s).
Different implementations may choose different modifications of the list
structure, as long as the function otherwise fulfills its contract. It
is an error to rely on the list destruction being performed in any
particular way. Any references to the list structure of the argument(s)
other than the value(s) returned are therefore undefined after the function
returns."
Rationale:
Benefits:
Implementations can improve performance of
many of the referenced functions when they are not under the constraint
to implement them in a specified fashion or "in the most logical
fashion". For example, on the Symbolics 3600, DELETE of a cdr-coded
list could use the implementation primitive %CHANGE-LIST-TO-CONS rather
than RPLACD to avoid creating forwarding pointers. As another example,
all of the destructive operations which remove objects could remove CAR
pointers to removed objects which are more volatile than the list
itself, assisting the garbage collector.
Most of the referenced functions implement abstract operations, for
example REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Aesthetics:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are currently in such danger, and this change to the documentation would
just publicize it. The clarification would ENCOURAGE good programming
practice by warning people to only obey the published contract of the
referenced functions.
Current practice:
Symbolics Common Lisp already implements some of the functions in a
non-obvious fashion. For example, in Symbolics Common Lisp:
(setq foo (list 'a 'b 'c)) ==> (a b c)
(setq bar (cdr foo)) ==> (b c)
(setq foo (delete 'b foo)) ==> (a c)
bar ==> ((c)) ; most people would guess (b c).
(eq (cdr foo) (car bar)) ==> t
Cost of adopting change:
There is no cost of adopting this change to developers.
------------------------------------------------------------
Alternative proposal: REMF-DESTRUCTION-UNSPECIFIED:DO-SPECIFY
Some or all of the functions could be documented to
perform the list destruction in a specified manner.
Rationale and Advantages: (1) The "additional features" may be more
useful to some programmers. (2) Programmers may expect the functions to
do the "expected" destructive operation. (3) Compatibility with other
dialects. For example, it may be easier to port a Zetalisp program to
Common-Lisp if REMPROP returns a sublist pointer as defined in Zetalisp.
If this alternative is pursued, then many implementations may be forced
to incompatibly change what their functions do. This may break existing
programs and may cause the implementation to have poorer performance.
∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: TAILP-NIL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:09:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:36:59 PDT
Date: 29 May 87 22:36 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: TAILP-NIL
to: CL-cleanup@Sail.stanford.edu
Message-ID: <870529-223659-1341@Xerox>
I've been putting this issue in the status list, but had never mailed it
out. It is not yet in proper format.
For the record:
Issue: TAILP-NIL
Reference: Steele p.275
Category: clarification
Description:
The description of tailp in Steele differs from current implementations
in the case where the first argument is NIL. In particular, the second
sentence "Another way to look at this is tailp is true if (nthcdr n
list) is sublist, for some value of n." does not accurately describe
current practice for the case where sublist is nil.
The behavior of TAILP on circular structures is also unspecified, e.g.,
is (tailp '() '#0=(x . #0#)) meaningful?
Proposal: TAILP-NIL:RETURN-NIL
Clarify that (TAILP NIL X) returns NIL for all lists X, and that tailp
must be true-false-indeterminate equivalent to
(defun tailp (x y)
(and x y (or (eq x y) (tailp x (cdr y)))))
i.e., if the second argument is circular and the first argument is not a
"tail" of the non-circular part of it, tailp may loop indefinitely.
∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:45:46 PDT
Date: 29 May 87 22:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
In-reply-to: Masinter.pa's message of 29 May 87 22:12 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224546-1347@Xerox>
I had written too many destructuring-bind's recently, and mistyped the
issue name as REMF-DESTRUCTURING-UNSPECIFIED. Sorry.
∂29-May-87 2310 Masinter.pa@Xerox.COM Status, Part 2
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:28 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, Part 2
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-224228-1344@Xerox>
This is part 2 of the status file. Please mail any corrections you have.
(I was closer to being done than I thought!)
PRINC-CHARACTER (Version 3)
Mailed by KMP 29-Apr-87.
Ready for release?
PROCLAIM-LEXICAL (Version 1)
In discussion
Reaching convergence
Need volunteer to merge comments into new version
PROMPT-FOR (Version 1)
Agreed to be controversial
Withdraw?
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not yet submitted.
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Withdraw?
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal.
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues.
∂29-May-87 2310 Masinter.pa@Xerox.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:47 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224247-1345@Xerox>
I found that I had fewer ballot items for the remaining issues on the
list -- just to liven it up, I stuck in a couple of ringers.
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂30-May-87 0715 MATHIS@ADA20.ISI.EDU Re: barrage of mail coming
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 May 87 07:15:38 PDT
Date: 30 May 1987 07:15-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: barrage of mail coming
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]30-May-87 07:15:01.MATHIS>
In-Reply-To: <870529-211317-1248@Xerox>
Larry,
How are we going to send this to the general membership of X3J13?
I can send you updated mailing labels. I also think that
electronic mail would be good.
I was thinking about the following style agenda for Boston:
Tuesday Morning -- clean-up committee
Tuesday afternoon -- Japanese characters presentation, X windows
presentation, administrative work of committee
Wednesday Morning -- clean-up committee
Wednesday afternoon -- remaining stuff
How does that sound to you?
Also, is it useful to have a meeting of this committee on Monday.
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
Bob
∂31-May-87 2051 masinter.pa@Xerox.COM ballots, meeting, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 May 87 20:50:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 31 MAY 87 20:50:05 PDT
From: masinter.pa@Xerox.COM
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>
I'd like to ask you, if you think you might have some opinions on some
or all of the issues, but don't have the time to respond now, to please
reply to that effect. I don't want to mail out proposals unless there is
consensus that they are ready for release.
MEETING:
I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.)
What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?
Other agenda items?
I expect to be flying in on Sunday, and so would be available all day
Monday. We probably will need to dig up a meeting room somewhere, too.
∂01-Jun-87 1217 JAR@AI.AI.MIT.EDU Status, Part 2
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 12:17:39 PDT
Date: Mon, 1 Jun 87 15:19:35 EDT
From: "Jonathan A. Rees" <JAR@AI.AI.MIT.EDU>
Subject: Status, Part 2
To: Masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of 29 May 87 22:42 PDT from Masinter.pa at Xerox.COM
Message-ID: <208084.870601.JAR@AI.AI.MIT.EDU>
Date: 29 May 87 22:42 PDT
From: Masinter.pa at Xerox.COM
PROCLAIM-LEXICAL (Version 1)
In discussion
Reaching convergence
Need volunteer to merge comments into new version
I think that "reaching convergence" is a little too optimistic.
∂01-Jun-87 1449 edsel!kent-state!eb@navajo.stanford.edu AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:49:34 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:00 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09873; Mon, 1 Jun 87 14:11:32 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07192; Mon, 1 Jun 87 14:11:22 PDT
Date: Mon, 1 Jun 87 14:11:22 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012111.AA07192@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: AREF-1D
I agree with Version 1, with one exception. I prefer the name
ROW-MAJOR-AREF to AREF-1D. With this change I support releasing this
proposal.
∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:50:09 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:14 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09918; Mon, 1 Jun 87 14:27:22 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07224; Mon, 1 Jun 87 14:27:11 PDT
Date: Mon, 1 Jun 87 14:27:11 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012127.AA07224@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: PATHNAME-SYMBOL
If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive. I believe that the aesthetics of the
language will be harmed by disallowing symbols as pathnames.
I'm not going to put up a fight to stop this change, but I would like
to see the minority view stated in the proposal.
∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:50:41 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:45 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09961; Mon, 1 Jun 87 14:39:45 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07238; Mon, 1 Jun 87 14:39:33 PDT
Date: Mon, 1 Jun 87 14:39:33 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012139.AA07238@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 29 May 87 21:27 PDT <870529-212725-1304@Xerox>
Subject: ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [x] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [x] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂01-Jun-87 1650 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 16:50:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 16:47:09 PDT
Date: 1 Jun 87 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-164709-3170@Xerox>
I don't like the current, 'concession to backward compatibility' which
allows apply, mapcar etc. to accept things which are not functionp. I
bet the amount of code which would be affected by this change is small,
and if we decide to make it now, vendors can make their systems warn
about it for a while, so the transition should not be too painful.
Face it, more code is going to be written than has already been written,
lets look to the future, not the past.
Now if only this argument could sway the Lisp-1 issue...
∂01-Jun-87 1715 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 17:14:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161104; Mon 1-Jun-87 20:14:13 EDT
Date: Mon, 1 Jun 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601-164709-3170@Xerox>
Message-ID: <870601201413.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Jun 87 16:46 PDT
From: Gregor.pa@Xerox.COM
I don't like the current, 'concession to backward compatibility' which
allows apply, mapcar etc. to accept things which are not functionp. I
bet the amount of code which would be affected by this change is small,
and if we decide to make it now, vendors can make their systems warn
about it for a while, so the transition should not be too painful.
This kind of warning strategy isn't very effective for things that cannot
be detected at compile time. A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.
∂01-Jun-87 1810 Pavel.pa@Xerox.COM AREF-1D
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:09:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:07:53 PDT
Date: 1 Jun 87 18:07 PDT
From: Pavel.pa@Xerox.COM
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
Message-ID: <870601-180753-3283@Xerox>
I favor this proposal in principal, but would much rather use the more
mnemonic name ROW-MAJOR-AREF instead of AREF-1D.
Pavel
∂01-Jun-87 1822 Pavel.pa@Xerox.COM DO-SYMBOLS-DUPLICATES
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:22:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:21:57 PDT
Date: 1 Jun 87 18:21 PDT
From: Pavel.pa@Xerox.COM
Subject: DO-SYMBOLS-DUPLICATES
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870601-182157-3303@Xerox>
I think that I favor something like the DO-SYMBOLS:ADD-KEYWORD proposal,
but I'm not willing to vote for it as it. The problem is that the
example in the proposal contains a keyword not described by the
proposal, namely :EXTERNAL-ONLY. Also, the proposal does not specify
which, if any, of the arguments following the return-value expression
are to be evaluated. In short, it is not a complete proposal.
I like the idea of having a single package-iteration macro, flushing
ones like DO-EXTERNAL-SYMBOLS. Probably the best way to do this is to
have some set of orthogonal attributes selectable by keyword. It would
be nice if the same keywords were the arguments to some functional
interface to package-iteration, such as the MAPATOMS function in
Interlisp. Then the flavor of the iterative macro would be more like
WITH-OPEN-FILE, whose options are just those available from OPEN.
In any case, I think that allowing the duplicates is probably the wrong
thing in general, so I can't vote in favor of either of the two
proposals.
Pavel
∂01-Jun-87 1830 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:29:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:29:18 PDT
Date: 1 Jun 87 18:29 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-182918-3312@Xerox>
Typo in the proposal:
``it is not synonomous to the use of the type FUNCTION'' should be ``it
is not synonomous with the use of the type FUNCTION''.
∂01-Jun-87 2041 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TAILP-NIL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:41:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161243; Mon 1-Jun-87 23:36:32 EDT
Date: Mon, 1 Jun 87 23:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL
To: CL-cleanup@Sail.stanford.edu
In-Reply-To: <870529-223659-1341@Xerox>
Message-ID: <870601233632.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I vote against releasing this issue until its writeup is in proper format.
When you write the current practice section, mention that Symbolics
follows the second of the two contradictory sentences in the tailp
writeup, hence (tailp nil <anything>) => t. This may mean that current
practice is not uniform.
For history, you can mention that the unambiguous definition in the
MIT Lisp Machine Manual (I consulted the fourth edition) would require
(tailp nil <anything>) => nil.
I personally don't care which disambiguation is adopted. If the writeup
includes a proposal to eliminate the function, I will vote for that, since
I've never understood what use tailp is.
∂01-Jun-87 2047 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:47:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161244; Mon 1-Jun-87 23:44:37 EDT
Date: Mon, 1 Jun 87 23:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212051-1278@Xerox>
Message-ID: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
...
Issue: IGNORE-ERRORS
...
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
Masinter wonders why KMP isn't spending more time on the error proposal.
...
I'd like to encourage you to remove this somewhat random comment, which may
be viewed by outsiders as being more critical than you hopefully meant. In
fact, KMP is spending a -lot- of time on the error proposal.
The problem is that KMP has what he thinks is a clear understanding
both of the length of time it takes to get things of that size through
a political mechanism such as X3J13 even under ordinary circumstances,
and is -very- leary about potential last-minute snags due to the
emergence of CLOS in parallel and the fact that people will likely
want last-minute "small changes" to make it take more advantage of CLOS.
The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me. The more vendors
who provide this as a private extension in the very near term, the fewer
utterly random interfaces they'll conjure instead. Like it or not, existing
code has to interface to the private extensions until this standard is marked
approved, but we can do a lot to improve quality of life by at least hinting
that this is coming. In Macsyma, there's a definition of IGNORE-ERRORS that
does:
#+LispM `(CONDITION-CASE (-ERROR-)
(VALUES (PROGN ,@FORMS) NIL)
(ZL:SYS:ERROR (VALUES NIL -ERROR-)))
#+(OR ...other-systems...)
`(LET ((RESULT (ERRSET (PROGN ,@FORMS) NIL)))
(IF RESULT
(VALUES (CAR RESULT) NIL)
(VALUES NIL T)))
#+(OR ...more-other-systems...)
...etc.
Each new case added requires careful study of the host error system to
figure out how to attach an IGNORE-ERRORS. If everyone had the idea that
at least IGNORE-ERRORS was worth latching onto, I think they'd at least
do that even if they weren't sure of the rest of the emerging error system,
and I think the resulting convergence would be very useful.
∂01-Jun-87 2050 Moon@STONY-BROOK.SCRC.Symbolics.COM PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:50:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161246; Mon 1-Jun-87 23:45:22 EDT
Date: Mon, 1 Jun 87 23:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL
To: Eric Benson <edsel!kent-state!eb@navajo.stanford.edu>, Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-ID: <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 1 Jun 87 14:27:11 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive. I believe that the aesthetics of the
language will be harmed by disallowing symbols as pathnames.
I'm not going to put up a fight to stop this change, but I would like
to see the minority view stated in the proposal.
Stating minority views in proposals is a good idea, but don't forget the
following point KMP made a couple of weeks ago. I only mention this
because the point about alphabetic case doesn't appear explicitly in the
version 2 writeup. I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase. This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.
* Note that the biggest impact of this change on users is that
they will not be able to say (LOAD'FOO) which they commonly type
interactively to mean (LOAD "FOO"). One advantage, of course, is
that in case-sensitive file systems, people won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not
found. Still, I think the fact that we're going to make it an
error for people to type (LOAD 'FOO) is worth documenting as part
of the cost of this proposal so that no one ends up surprised.
One note I had about KMP's remark:
Nothing in CLtL says that a symbol is allowed as an argument to LOAD,
unless we take all occurrences of the string "filename" in italics
to be typos for "pathname" in italics. See pp.413,418,426.
∂01-Jun-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:55:06 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161252; Mon 1-Jun-87 23:53:19 EDT
Date: Mon, 1 Jun 87 23:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I changed my name from KMP to Pitman in a bunch of proposals
because I thought it would be better for the X3J13 people who
aren't regular readers of net mail and might not put the two
together.
I notice in your summaries that sometimes I come out as KMP
and other times as Pitman. I'd appreciate if you could either
change the ones I missed to say Pitman or publish an index
that says what a KMP is (in which case I'd like to be KMP
everywhere).
Presumably, the same reasoning should apply for SEF, etc.
In fact, SEF doesn't even use the name SEF as his login name,
so that may be even more confusing to some.
Once we adopt a convention, we can just use it regularly and then
there need be no further last-minute touch-ups of this sort.
∂01-Jun-87 2121 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue 2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-211904-1265@Xerox>
Message-ID: <870602001135.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
Even though there is a predicate FUNCTIONP, it is not synonomous to the
use of the type FUNCTION; the FUNCTION type cannot be used for
discrimination.
I don't think that's true. I believe CLtL p.47 is meant to say that a
list type-specifier with FUNCTION in the car cannot be used for
discrimination, while Table 4-1 combined with CLtL p.72 indicates that
the symbol type-specifier FUNCTION can be used with TYPEP. I would
simply remove this paragraph from the proposal. Later in the proposal
you have an explicit statement that the symbol type-specifier FUNCTION
can be used for discrimination.
This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
If it also removes the COMPILED-FUNCTION type-specifier, say so here.
∂01-Jun-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:22:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161269; Tue 2-Jun-87 00:12:38 EDT
Date: Tue, 2 Jun 87 00:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870601-180753-3283@Xerox>
Message-ID: <870602001244.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Jun 87 18:07 PDT
From: Pavel.pa@Xerox.COM
I favor this proposal in principal, but would much rather use the more
mnemonic name ROW-MAJOR-AREF instead of AREF-1D.
I agree.
∂01-Jun-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:21:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161264; Tue 2-Jun-87 00:09:32 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870529-212341-1290@Xerox>
Message-ID: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.
It came through looking like this to me:
...
Rationale:
The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a
symbol
here was that it did not have strings at all. However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
...
Also, I find the treatment of LOAD is not uniformly carried through.
For example, the proposal mentions LOAD at one point under conversion
cost. It may want to mention it under aesthetics, too. But in any case,
it should surely state definitively that LOAD is affected in the Proposal
and the References.
By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
so the comment saying we've long since flushed the feature is not completely
accurate. It may be that Moon didn't mean to include LOAD, in which case
the discussion should be phrased to make it clear that LOAD is not intended.
I think this will be a likely source of grumbling at X3J13; we might as
well head it off early. I won't vote to release this until the wording is
made to treat LOAD clearly.
∂01-Jun-87 2126 Moon@STONY-BROOK.SCRC.Symbolics.COM ***BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:26:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161284; Tue 2-Jun-87 00:25:41 EDT
Date: Tue, 2 Jun 87 00:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ***BALLOT ***
To: cl-cleanup@Sail.stanford.edu
In-Reply-To: The message of 30 May 87 00:27 EDT from Masinter.pa@Xerox.COM,
<870529-212725-1304@Xerox>,
The message of 30 May 87 01:42 EDT from Masinter.pa@Xerox.COM,
<870529-224247-1345@Xerox>
Message-ID: <870602002546.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are my votes on both part 1 and part 2 of the ballot:
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
;Okay for release if name is changed to ROW-MAJOR-AREF
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
;I don't have comments to offer on this, but it does seem
;that there is some justification for not releasing it,
;instead replacing it with a more complex proposal involving
;lots of keyword options. However I can't support
;DO-SYMBOLS:ADD-KEYWORD in its present incomplete form.
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
;Okay for release if the two comments I sent in mail are addressed
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
I cannot vote on the following, as I have not received copies of them.
Or if I have, it was so long ago that I have lost them, and even if
I hadn't lost them, I wouldn't trust them to be up to date.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
;If those are the only two choices, "withdraw" always wins!
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
;I support strict left to right evaluation order, which I believe
;to be the current definition of Common Lisp. I can't figure
;out which checkbox means left-to-right.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂01-Jun-87 2137 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:36:36 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161299; Tue 2-Jun-87 00:35:40 EDT
Date: Tue, 2 Jun 87 00:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 3)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870602003737.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Changes since version 2:
* Pavel's request to strike reference to ~Q at the end of the
Problem Description field.
* Masinter's request to reword proposal to not talk directly about
modifying CLtL in the Proposal field.
* The last paragraph of the Discussion field is new.
-kmp
-----Proposal Follows-----
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
29-Apr-87, Version 3 by Pitman (misc editing)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and
~:C equivalently or very similarly, which seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. Leave the behavior
of ~C with non-zero bits incompletely specified. For example, the
description of ~C on p389 of CLTL might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Clarify that WRITE-CHAR puts only one character on its argument stream,
but which allows that stream to perform arbitrary destination-dependent
actions based upon that character:
Note: The glyphs used to present characters which are not in
the standard character set may vary from implementation to
implementation or output device to output device. WRITE-CHAR
will always output a single character to the indicated stream.
On some streams, super-quoting, character substitution, or
substitution of a string for a single character may be
necessary; it is appropriate for the stream to decide to do
this, but WRITE-CHAR itself will never do this.
Rationale:
This was probably the intent of the authors.
It makes things clear enough that programmers can know what to
expect in the normal case (standard characters with zero bits)
while leaving some flexibility to implementors about what to do in
the case of bits (which are not particularly well-defined across
different implementations anyway).
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
KMP and Pavel support this proposal.
KMP thinks it's important to get this cleared up as soon as possible.
Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
identical in all cases) was:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
Steele and Fahlman seemed to like the idea of the proposal if amended
as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
blow it somehow, they should now be happy.
Moon and Fahlman voiced support for version 2.
Fahlman thinks the problem description is too long.
KMP isn't sure if he agrees that the problem description is too long,
but doesn't think it's worth anyone's time to edit it.
∂01-Jun-87 2151 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:50:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161302; Tue 2-Jun-87 00:41:11 EDT
Date: Tue, 2 Jun 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602004111.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
From: Kent M Pitman <KMP@STONY-BROOK>
The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me.
In light of this, I'd like to modify my vote to say that I don't care
whether IGNORE-ERRORS is released in its present form (minus gratuitous
personal comments about how KMP spends his time) or withdrawn in
deference to the error proposal.
∂01-Jun-87 2152 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:52:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161307; Tue 2-Jun-87 00:51:50 EDT
Date: Tue, 2 Jun 87 00:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602005157.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 2 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.
This happens to most mail that passes through Xerox. I don't think they
see it in their own mail reader, but in the outside world it gets
reformatted as alternating long and short lines if the lines are longer
than a small maximum.
By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
so the comment saying we've long since flushed the feature is not completely
accurate.
Try ZL:LOAD if you want to see what it does in Zetalisp. But CL:LOAD doesn't
allow symbols in 7.1 for me, so maybe you've "fixed" it in your init file?
I don't think I've "fixed" it in mine.
It may be that Moon didn't mean to include LOAD, in which case
the discussion should be phrased to make it clear that LOAD is not intended.
CLtL already does not say that LOAD accepts symbols as arguments, unless we
are to think that when it says "filename" it means "pathname", and when it
discusses what arguments named "pathname" mean 13 pages earlier, it means to
include LOAD.
I certainly didn't mean to propose to change the language to make LOAD allow
symbols.
Does this mean that we need to withdraw PATHNAME-SYMBOL in favor of a more
comprehensive proposal to fix all the ambiguities and incomplete specifications
in chapter 23? That would be nice, but it's a big job. Maybe we could just
cover every argument that is called pathname, filename, file, or new-name
and leave the rest of the ambiguities for another proposal?
∂01-Jun-87 2209 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 22:09:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161319; Tue 2-Jun-87 01:08:02 EDT
Date: Tue, 2 Jun 87 01:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: Masinter.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870529-211354-1250@Xerox>
Message-ID: <870602010958.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
Issue: ADJUST-ARRAY-DISPLACEMENT
I'm happy with most of this clarification as far as it goes, but I have a
few other things that I'd like to see cleaned up before it goes out...
...
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element. However, the use of
:initial-contents causes all old contents to be discarded.
Hmm. I can almost get COPY-ARRAY out of this, couldn't I? Maybe...
(DEFUN COPY-ARRAY (ARRAY)
(ADJUST-ARRAY (MAKE-ARRAY (ARRAY-DIMENSIONS ARRAY)
:ELEMENT-TYPE (ARRAY-ELEMENT-TYPE ARRAY)
:DISPLACED-TO ARRAY)
:DISPLACED-TO NIL))
This isn't one of the things I necessarily think needs clarification. I just
thought it was curious. The rest of this message is of more significant interest.
Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y. ...
I'm happy with this statement, but it sounds like it follows from one or
more of the four previous rules, and I'm not clear which. If it really
redundant, perhaps you could make the reason more clear. If not, it
shouldn't begin with "Note that...".
As nearly as I can tell, the discussion of ADJUST-ARRAY both here and in
CLtL does not say what happens if :DISPLACED-TO is omitted. Ie, is
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A))
the same as
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO NIL)
or the same as
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO A)
?
The current style of wording looks like the sort of clever :ADJUSTABLE
wording that got us into such a frenzy. Even if there's intentional ambiguity,
we should be clear about that fact. My guess, though, is that no ambiguity
was intended here.
∂01-Jun-87 2221 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 22:20:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161330; Tue 2-Jun-87 01:20:11 EDT
Date: Tue, 2 Jun 87 01:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I changed the name of the function from AREF-1D to ROW-MAJOR-AREF,
re-filled some of the text to fit better in 80-columns, and marked
KMP, GLS, Moon, JonL, Benson, and Pavel as supporting this amended
version in the Discussion field. Other than that, no changes.
-----Proposal Follows-----
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman,
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
Status: For Internal Discussion
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying
arity. Currently, you have to make a displaced array to work with
temporarily and then throw away the displaced array when you're done.
In the case of FILLARRAY, I find this bothersome because there is no
a priori reason why FILLARRAY should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF which allows 1D access to the
storage backing up a given array assuming the normal row-major storage
layout.
This accessor should be valid for use with SETF.
Rationale:
We already document the row-major storage layout and have a number of
operators which allow users to exploit that order. This would be a
useful addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this involves
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name
for use internally. In Symbolics systems, for example, it is
SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations which already
use this primitive internally, it's little more than a matter of
changing the name of or otherwise releasing the existing primitive.
In some implementations, it might involve writing a small amount of
code (and associated compiler optimizers).
Benefits:
This gives users efficient access to something which they already have
inefficient access to.
Conversion Cost:
This is an upward-compatible change.
Aesthetics:
I think this allows certain programs to be written in a more aesthetic way.
Discussion:
KMP and GLS support this proposal.
Moon, JonL, Benson, and Pavel expressed conditional support of version 1,
asking that the name be changed from AREF-1D to ROW-MAJOR-AREF. KMP and
GLS did not oppose this change, so it was made for version 2.
∂02-Jun-87 0041 masinter.pa@Xerox.COM schedule
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87 00:41:40 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 02 JUN 87 00:41:13 PDT
From: masinter.pa@Xerox.COM
Date: 2 Jun 87 0:40:46 PDT
Subject: schedule
To: cl-cleanup@sail.stanford.edu
Message-ID: <870602-004113-3549@Xerox>
I've gotten several ballots, but by no means all.
I'll be out tomorrow and fairly busy on Wednesday, so I thought I could
summarize the ballots on Thursday, mail out revised versions of any of
the proposals that had only typographical corrections to this group and
a revised status.
My target for mailing to X3J13 is next week. (Bob Mathis, if you are
listening, please send mailing labels!!!)
∂02-Jun-87 0226 KMP@STONY-BROOK.SCRC.Symbolics.COM *** BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Jun 87 02:26:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161499; Tue 2-Jun-87 05:25:43 EDT
Date: Tue, 2 Jun 87 05:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *** BALLOT ***
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212725-1304@Xerox>,
<870529-224247-1345@Xerox>
Message-ID: <870602052736.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
ADJUST-ARRAY-DISPLACEMENT (revision 1)
BALLOT: [ ] Release as is [x] Comments precede in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments precede in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
[x] Release version 2
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD
[x] Other: comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
Note: I'd really be happiest if this was broken in two, so I could
support the half I like and only grump about the parts I don't
like. If we're going to deal with it all as one bundle, I feel
obliged to hold up the whole thing for a bit because I believe
there is useful progress still to be made amongst ourselves
prior to releasing this to the masses.
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
Note: I would like to see NIL be allowed to designate the null lexical
environment, but I won't hold up the proposal for this if anyone
disagrees.
IF-BODY (Version 5)
BALLOT: [x] Release as is
[ ] Wait for version that SEF and KMP agree is "fair".
Note: I'm not trying to be pushy; I just assume I must vote Yes to
avoid a gentleman's deadlock. If SEF disagrees and wants to do
further editing, I'm willing to have this put on hold for another
round. I don't plan to let this fall victim to a pocket veto,
however.
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal
[ ] Comments follow in mail to cl-cleanup
[x] Release with minor changes to discussion as mentioned in
recent mail.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
Note: The copy of this which I received recently has been filled
oddly and needs to be reformated if it looked that way before
it went through someone's (Larry's?) mailer.
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal.
[ ] Comments follow in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
Note: This term "withdraw" really bugs me. These item names are the names
of issues, not proposals. The proposal names have ":something"
appended. Seems to me that issues oughtn't get withdrawn, they
should just be placed on hold.
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first)
[ ] unspecified [ ] Proposal follows in mail to cl-cleanup
Note: I'm not sure if this ballot item is for real. Clearly the topic
warrants serious discussion, but I have no opinion right now so am
not going to risk it.
PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED
[ ] Something else [x] Undecided
Note: I am not clear on whether I support GENERALIZE or MODIFIED. I want to
spend more time looking at this when I get a chance. I don't think we
should propose anything firm yet.
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal
[ ] Want proposal for removing BITS and FONT from standard
[ ] Want fuller character proposal
[ ] Comments follows in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
∂02-Jun-87 1016 RPG Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
Moon writes about Gregor's suggestion to warn on bad arguments to APPLY:
``This kind of warning strategy isn't very effective for things that cannot
be detected at compile time. A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.''
This might be right, but I'd rather there be an annoyance during a
period when old code is fixed than have years of bad news simply because
of a sentimental attachment to MacLisp. Here's my proposal: Let the vendors
make the change and let the users fix their code.
-rpg-
∂02-Jun-87 1148 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87 11:48:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUN 87 11:32:42 PDT
Date: 2 Jun 87 11:32 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 1 Jun 87 20:14 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870602-113242-4179@Xerox>
Date: Mon, 1 Jun 87 20:14 EDT
From: David A. Moon
This kind of warning strategy isn't very effective for things
that cannot be detected at compile time. A run time warning tends
to be a big annoyance and may not tell you just where in your
program was responsible for the effect.
True, but I think many of the cases could in fact be detected at run
time. Of course I have not done an extensive search, and there may well
be large bodies of code for which this is not true. Those large bodies
of code will require hand analysis and conversion.
Here is another point which I think is relevant to this discussion.
Define the Z of a lisp programmer to be their familiarity with the
subleties of Lisp programming. This includes things like the history of
Lisp, what dynamically scoped Lisps are like, what Lisp-1s are like etc.
etc. It seems to me that as time goes on, the average Z of lisp
programmers is going to go down. In some sense, that is what it means
for Lisp to become a successful language. An effect of this, is that in
most cases, it is going to be much easier for the people who have
written the existing code to deal with a change like the one I am
suggesting, than it will be for future programmers to deal with the
confusion caused by not making the change. This is over and above the
fact that there will be much more code 5 years from now (we all hope!).
Take the example of Macsyma (or Spire or Kee or any other large 'old
time but still in use' Lisp program). What if this change breaks one of
them? We have to weigh that with the cost of propagating past confusion
by making apply and friends do conversion. But the people who maintain
systems like Macsyma and KEE are likely much higher Z programmers than
people who are writing new code. It probably won't be real hard for
these old time people to make this change. It is more likely that the
new lisp programmers will get confused and write bad code. I supect
people will write
(squirrel-function-away-1 '(lambda (x) ..))
(squirrel-function-away-2 #'(lambda (x) ..))
(funcall (fetch-function-1) (some-data))
(funcall (fetch-function-2) (some-data))
Since both 'functions', when they are fetched and funcalled will work,
people won't notice that the one isn't compiled. When and if they do
notice, it may take them a long time to understand why they are losing
this way.
∂02-Jun-87 1219 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jun 87 12:19:07 PDT
Received: by navajo.stanford.edu; Tue, 2 Jun 87 12:14:59 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA13431; Tue, 2 Jun 87 11:53:27 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA08307; Tue, 2 Jun 87 11:53:18 PDT
Date: Tue, 2 Jun 87 11:53:18 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706021853.AA08307@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 1 Jun 87 23:45 EDT <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL
Date: Mon, 1 Jun 87 23:45 EDT
From: David A. Moon <navajo!Moon@STONY-BROOK.SCRC.Symbolics.COM>
Line-Fold: No
I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase. This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.
I don't enjoy a file system with case-sensitive names, but I seem to
be stuck with it! Our VMS users like to be able to type (load 'foo),
though.
I think you've made a better case for eliminating the coercion of
symbols to strings, rather than making a special case restriction
against using a symbol as a string to be coerced to a pathname. You
have also made a case for making the boolean falsehood value be
something other than a symbol. Making this special case restriction
against symbols as pathnames is treating the symptom and not the
disease.
∂03-Jun-87 0729 gls@Think.COM ***BALLOT *** PART 1 *** My reply
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:29:40 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:31:54 EDT
Date: Wed, 3 Jun 87 10:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 1 *** My reply
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-212725-1304@Xerox>
Message-Id: <870603102930.2.GLS@BOETHIUS.THINK.COM>
Date: 29 May 87 21:27 PDT
From: Masinter.pa@xerox.com
Please vote on the following issues which are open. "Release" means to
release the document to X3J13 for discussion & voting.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[X] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [X] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [X] Release as is [ ] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [X] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [X] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
∂03-Jun-87 0731 gls@Think.COM DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:31:42 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:34:03 EDT
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
Message-Id: <870603103149.3.GLS@BOETHIUS.THINK.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other? Do we
need a provision that DO-SYMBOLS must terminate, at least
for cases where the body does not aletr the packages involved?
--Guy
∂03-Jun-87 0733 gls@Think.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:33:21 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:35:51 EDT
Date: Wed, 3 Jun 87 10:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-224247-1345@Xerox>
Message-Id: <870603103338.4.GLS@BOETHIUS.THINK.COM>
∂03-Jun-87 0749 gls@Think.COM June X3J13 meeting
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:48:54 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:48:46 EDT
Date: Wed, 3 Jun 87 10:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: June X3J13 meeting
To: MATHIS@ada20.isi.edu
Cc: cl-cleanup@sail.stanford.edu
Message-Id: <870603104633.8.GLS@BOETHIUS.THINK.COM>
I regret that for personal and business reasons I will
be out of town on the days of the June meeting, and
therefore cannot attend. Thinking Machines will send
an alternate representative.
--Guy
∂03-Jun-87 0809 gls@think.com Transitivity of coercions
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 08:09:29 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 3 Jun 87 08:06:27 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 11:11:12 EDT
Date: Wed, 3 Jun 87 11:09 EDT
From: Guy Steele <gls@think.com>
Subject: Transitivity of coercions
To: edsel!kent-state!eb@navajo.stanford.edu,
navajo!cl-cleanup%sail@navajo.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-Id: <870603110900.0.GLS@BOETHIUS.THINK.COM>
Note that an explicit decision was made early in the design of CL
not to make all coercions transitive. For example, symbols
coerce to strings (for string functions), and strings are sequences
(and so can be mixed with other sequence types), but symbols are
not sequences.
If we cannot have consistency, let us then have consistency of
inconsistency. (Also known as, "This screw-up was good enough
for grampa, and it's good enough for me!")
--Guy
∂03-Jun-87 0926 gls@Think.COM People's names :-)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 09:26:28 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 12:29:08 EDT
Date: Wed, 3 Jun 87 12:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: People's names :-)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>
A proposed standard for establishing naming standards for CL-CLEANUP proposals
Any message sent to CL-CLEANUP whose subject line consists solely of the
word "AXOLOTL" (in all upper case, possibly with surrounding whitespace)
may contain lines of the form
#REWRITE "xxx" => "yyyyy" comment
where xxx and yyyyy may be any strings. Such a line specifies that
henceforth in a CL-CLEANUP proposal any word-delimited substring "xxx"
of the proposal shall be replaced by "yyyyy". The comment may be any text
(possibly empty).
Masinter can collect these strings and use a software tool to apply them
all to each proposal as it is sent out. Rewrite rules shall be ordered,
first according to the timestamp of the message defining them (earliest
first), secondarily according to alphabetical order of sender (to break
timestamp ties), and lastly according to the order in which the rules
appear in the message (in case a message defines more than one rewrite
rule). When each rule is applied to a message, the leftmost occurrence
of "xxx" is located and replaced by "yyyyy"; the rule is then applied
again only to the remaining unsearched text, not to "yyyyy" or the text
that precedes it. This allows a rule that rewrites "loser" into
"incredible loser" to avoid infinite recursion.
A rule that rewrites a person's name into another form is automatically
adopted when proposed by that person unless vetoed by a 2/3 majority
of CL-CLEANUP. When proposed by another person it can be adopted only
after a show of 2/3 support. Any other rewrite rule is included or
not at the discretion of Masinter unless overridden by 2/3 vote.
For example (note that the following examples do not actually take
effect because the subject line of this message is not "AXOLOTL"):
#REWRITE "KMP" => "Pitman" Needs 2/3 vote to take effect unless
KMP should propose it himself
#REWRITE "GLS" => "Steele"
#REWRITE "mantissa" => "significand"
#REWRITE "that bagbiter Quux" => "that remarkable fellow Steele"
--Quux
P.S. Other extensions suggest themselves. For example, a line
of the form #FLUSH "xxx" in any message whose header contains
":-)" could mean that any message containing "xxx" should be
killed by the mailer at SAIL and not distributed to CL-CLEANUP
at all.
#FLUSH "#REWRITE"
∂03-Jun-87 1101 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 11:01:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 162940; Wed 3-Jun-87 14:00:15 EDT
Date: Wed, 3 Jun 87 14:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603103149.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other?
I don't think this is a problem, since using a package does not
inherit symbols that are -accessible- to that package, only
symbols that are -exported- by that package.
∂03-Jun-87 1154 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names :-}
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 11:54:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163006; Wed 3-Jun-87 14:53:19 EDT
Date: Wed, 3 Jun 87 14:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names :-}
To: RPG@SAIL.STANFORD.EDU
cc: gls@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@sail.stanford.edu
In-Reply-To: <870603122658.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603145314.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
There seems to be some bug in the SAIL mailer. I received the following
piece of mail, which was apparently not intended for me (or anyone on
CL-Cleanup, for that matter).
Please fix the mailer to prescan the text of messages and to make any
suggested improvements in itself -prior- to sending the mail in which
it reads about said improvements so that it can take advantage of those
improvements at the earliest opportunity.
Please be sure the mailer does not try to re-read the suggestion after
improving itself, however. This will avoid embarrassing halting problems
that could result from the improvement changing its understanding of the
suggestion.
-----
Date: Wed, 3 Jun 87 12:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: People's names :-)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>
[text of message omitted]
∂03-Jun-87 1332 gls@Think.COM DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 13:31:51 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 16:31:30 EDT
Date: Wed, 3 Jun 87 16:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: Moon@stony-brook.scrc.symbolics.com, gls@think.com
Cc: cl-cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870603162917.0.GLS@BOETHIUS.THINK.COM>
Date: Wed, 3 Jun 87 14:00 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other?
I don't think this is a problem, since using a package does not
inherit symbols that are -accessible- to that package, only
symbols that are -exported- by that package.
Right. Sorry. So suppose each of two packages uses the other,
and each happens to export the same symbol?
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B:ASYM B)
(USE-PACKAGE B A)
(DO-ALL-SYMBOLS (X B) (PRINT X)) ;will this print ASYM once, twice,
; an infinite number of times, or what?
--Guy
∂03-Jun-87 1906 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 19:05:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163448; Wed 3-Jun-87 22:04:49 EDT
Date: Wed, 3 Jun 87 22:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603162917.0.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603220443.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 16:29 EDT
From: Guy Steele <gls@Think.COM>
So suppose each of two packages uses the other,
and each happens to export the same symbol?
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B:ASYM B)
(USE-PACKAGE B A)
(DO-ALL-SYMBOLS (X B) (PRINT X)) ;will this print ASYM once, twice,
; an infinite number of times, or what?
DO-SYMBOLS:ALLOWED proposes to allow it to print ASYM once or twice, the
way I read it. I don't see how it could print it an infinite number of
times. (package-use-list (find-package 'a)) has no effect on
(package-external-symbols (find-package 'a)), hence should have no effect
on (do-symbols (x b) ...). Or are you saying that the specification
should be loosened up to the point where do-symbols is allowed to
recurse on packages used, and then only look at a subset of the symbols
in those packages?
Nit picking: I assume you meant (DO-SYMBOLS (X B) (PRINT X)) rather
than (DO-ALL-SYMBOLS (X B) (PRINT X)). I have no idea how many times
the latter should print ASYM, before it returns the value of B, except
that it shouldn't be an infinite number.
package-external-symbols is missing from the Common Lisp language for
some unfathomable reason, but you can define it in terms of do-external-symbols.
The example didn't run until I changed B:ASYM to B::ASYM.
End of nit picking: Does this mean the DO-SYMBOLS issue file needs to be
beefed up to discuss these issues, or are you and I just rambling while
waiting for our Thinking Machines (TM) central nervous system prosthetics
to be installed?
∂03-Jun-87 2038 FAHLMAN@C.CS.CMU.EDU PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 20:38:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:37:15-EDT
Date: Wed, 3 Jun 1987 23:37 EDT
Message-ID: <FAHLMAN.12307700341.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: edsel!kent-state!eb@λnavajo.stanford.edu (Eric Benson)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: PATHNAME-SYMBOL
In-reply-to: Msg of 2 Jun 1987 14:53-EDT from edsel!kent-state!eb at navajo.stanford.edu (Eric Benson)
I think you've made a better case for eliminating the coercion of
symbols to strings, rather than making a special case restriction
against using a symbol as a string to be coerced to a pathname. You
have also made a case for making the boolean falsehood value be
something other than a symbol. Making this special case restriction
against symbols as pathnames is treating the symptom and not the
disease.
Treating the symptom rather than the disease is often the best way to
keep the patient alive. Let's fix what we can and think about more
extensive redesigns later.
-- Scott
∂03-Jun-87 2104 FAHLMAN@C.CS.CMU.EDU General strategy
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:04:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:56:39-EDT
Date: Wed, 3 Jun 1987 23:56 EDT
Message-ID: <FAHLMAN.12307703872.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: General strategy
Before I start voting and commenting on specific issues, I'd like to
raise a point about our general strategy.
On important issues, where there is real disagreement within the cleanup
committee or where the issue is so critical that all sides must be
carefully explained, it is important that we present the issue with
multiple proposals and that the choosing is done by X3J13 as a whole.
On the other hand, a lot of these issues are trivial little things that
need to be cleaned up one way or another. I believe that X3J13 and the
Common Lisp community as a whole want these to be resolved without a lot
of needless agonizing, and they want this committee to provide the
leadership to get that job done. If there are two or three solutions to
some issue that differ only in "aesthetics", we on the cleanup committee
should converge on one solution, propose it, and endorse it.
We shouldn't say, "Well, we could do A and then again we could B, but
someone suggeted C and that's OK too." Instead, we should say, "We
propose A." In the discussion section we should say, "Solutions B and C
were discussed, but the cleanup committee has settled on A as the best
solution." If we send multiple-choice proposals to X3J13 on trivial
issues where it doesn't matter, the discussion will focus on those
stupid things and much more important issues will be neglected.
A number of the proposals currently offer useless options of this kind,
either as actual choices to be voted on or as variations suggested in
the discussion section. We should try to resolve these among ourselves
rather than leaving them hanging. I'm not worried about people
following us blindly -- X3J13 seems to have enough sharp and contentious
people on it to prevent any abuse of this power.
-- Scott
∂03-Jun-87 2124 FAHLMAN@C.CS.CMU.EDU Ballot, parts 1 and 2
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:24:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:23:54-EDT
Date: Thu, 4 Jun 1987 00:23 EDT
Message-ID: <FAHLMAN.12307708833.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Ballot, parts 1 and 2
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [x] Comments follow in mail to cl-cleanup
; OK in substance, but I'd like an edit to the discussion section.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
; Or, if whoever proposed it insists, bring it out with a negative
; recommendation and let it be defeated once and for all.
ROW-MAJOR-AREF (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; I prefer KMP's version 2 with the name change.
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; But first proofread the "adoption cost" section.
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [x] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; Proofread "Conversion Cost" section.
IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair". [ ] Comment follows.
IGNORE-ERRORS (Version 3)
BALLOT: [x] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
; Eliminating the question about KMP's priorities.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments
follow in mail to cl-cleanup
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
; I'm not going to vote on anything not yet submitted or discussed. I'm
; not likely to favor any proposal that deviates from deterministic
; left-to-right evaluation, however.
PROMPT-FOR (revision 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments follow in
mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else
[x] Undecided
; Someone needs to take the lead in boiling this down to a single
; coherent proposal.
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
; ??? I don't seem to have a recent version of this. I'd like a
; redesign of the whole font/bits business, but might support a quick
; fix in the meantime.
∂03-Jun-87 2135 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:35:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:34:58-EDT
Date: Thu, 4 Jun 1987 00:34 EDT
Message-ID: <FAHLMAN.12307710848.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: Msg of 30 May 1987 00:13-EDT from Masinter.pa at Xerox.COM
I support this proposal and have no problem with releasing it as-is,
except for the form in which Moon's comments are included at the end.
As it stands, this is one of those proposals that seems to say, "Let's
do A, but then again we might want to do B."
Unless Moon wants to push the alternative he raises, we should either
drop this comment or say something like the following:
"Moon pointed out that the Symbolics system currently does ..., and that
this is an equally viable alternative. However, the committee has
decided to stick with the proposal as described above."
If Moon strongly favors the alternative he describes, I could support
that as well. I just think we need to pick one or the other. This is
one of those cases where a clear and definite stand by the
cleanup committee would prevent the larger committee from getting bogged
down in needless details.
∂03-Jun-87 2145 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:44:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:44:18-EDT
Date: Thu, 4 Jun 1987 00:44 EDT
Message-ID: <FAHLMAN.12307712547.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 2)
In-reply-to: Msg of 30 May 1987 00:16-EDT from Masinter.pa at Xerox.COM
I support DO-SYMBOLS-DUPLICATES:ALLOWED.
I don't think we should present X3J13 with two alterantives on a dumb
issue like this. If someone really feels strongly about the keyword
version and wants to produce a correct and complete version of the
keyword proposal in the next couple of days, I would be willing to go
along with that instead. But in any case, I think we should decide
among ourselves and only bring one proposal out of this committee.
If we do go with a keyword version, I feel rather strongly that the
default must be to allow duplicates. In most cases, the issue of
duplicates really doesn't matter, and we don't want to saddle users with
a much more expensive default.
-- Scott
∂03-Jun-87 2201 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:01:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:00:44-EDT
Date: Thu, 4 Jun 1987 01:00 EDT
Message-ID: <FAHLMAN.12307715536.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
I'm willing to go along with releasing KMP's latest revision of IF-BODY,
even though it doesn't properly argue the case that manufacturers should
provide reasonable portability tools before using non-portability as an
argument for changing the language.
I am confident that this proposal will be defeated and then we'll be
done with it. If I am wrong, I can probably live with that. (Of
course, any CMU programmers caught using extended-IF would get a "mild"
electric shock to remind them that legal Common Lisp is not necessarily
acceptable Common Lisp.)
What is important to me is not that we hold up this particular issue,
but that in the future we adopt an adversarial system for putting
together proposals on which we cannot reach a consensus. Nobody should
be put in the position of having to summarize a position he doesn't
agree with; it's a very difficult, thankless task for the summarizer,
and the opposition is likely to feel screwed anyway. Each side should
get some space in which to argue its case, and nobody should edit the
result.
-- Scott
∂03-Jun-87 2232 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:32:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:31:53-EDT
Date: Thu, 4 Jun 1987 01:31 EDT
Message-ID: <FAHLMAN.12307721211.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Msg of 30 May 1987 00:18-EDT from Masinter.pa at Xerox.COM
There seem to be three positions here:
1. The "maximally clean" proposal, in which FUNCALL, APPLY, and the
built-in functions that take functional args would take only true
functions and it would "be an error" to pass either of these a lambda
expression or a symbol.
2. The "maximally compatbile" proposal currently reflected by
FUNCTION-TYPE:REDEFINE.
3. The "maximally Macsyma" proposal, which is like 2 but would also
require that SYMBOL-FUNCTION take a symbol or lambda and return it
unchanged.
I actually favor option 1, though I think that we must be up-front about
the incompatibilities it introduces. Several others seem to share this
view.
It might be hard to get the majority of X3J13 to agree to option 1,
however, since a lot of those people are more worried about preserving
existing code than about cleanliness and consistency. If we want to
resolve this issue in a hurry, pushing option 2 might be the way to go.
Moon has been the most vocal advocate of option 2 within the cleanup
committee. Personally, I could live with this, though I prefer option
1.
So far, only KMP has argued in favor of option 3. This does not reflect
the status quo in many implementations, and some of us view it as a step
backwards.
It would be great if we could reach some internal consensus on this
issue and present a recommendation from the whole cleanup committee. If
this is impossible, we should write this up as a two-option or
three-option proposal and let X3J13 fight it out. I don't think we
should sit on this indefinitely waiting for someone's mind to change or
break it up into little pieces -- either move will just guarantee that
this remains unresolved for the forseeable future.
If people are comfortable with releasing the current version, I can go
along with that in priciple, but the presentation needs to be cleaned up.
I will be happy to do some of the work of redrafting this proposal, but
can't do this without understanding where the committee members stand:
what they favor, and what they would agree to.
-- Scott
∂03-Jun-87 2238 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:37:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:37:10-EDT
Date: Thu, 4 Jun 1987 01:37 EDT
Message-ID: <FAHLMAN.12307722170.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
In-reply-to: Msg of 30 May 1987 00:22-EDT from Masinter.pa at Xerox.COM
I support this proposal and support releasing it as-is, except for the
next to last paragraph about NIL. Another dangling issue, and this time
it seems like the sentence, "The cleanup committee supports this change"
refers to the exclusion of NIL.
I don't care whether we decide that NIL should be allowed or disallowed,
but we should decide on one or the other and say so clearly, not just
mumble on both sides of the issue with no resolution.
-- Scott
∂04-Jun-87 0852 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
When Clinger and I proposed this cleanup, it was the maximally clean
version, and that is the one I support. On the other hand, I believe that
there is little reason to actually press for the maximally clean version.
In some sense, all of us are trying to ``spread the word'' about Lisp,
trying to get currently non-Lisp programmers to switch. We could do this
if there were some way for mainstream computing to be done in Lisp.
With a language like Common Lisp this is not possible - it is too big
and it is growing. What we could have hoped to accomplish with this
cleanup is a first step towards establishing a continuum of Lisps from
Scheme up through Common Lisp. Even if we were to adopt this change, the
period until we had the continuum would be lengthy.
I don't think we can win this game quickly given the time constraints
and the current state of Common Lisp. We continue to argue about the
filigrees.
I believe that we ought to minimally clean up Common Lisp and rapidly
move on to the next great Lisp language design.
-rpg-
∂04-Jun-87 1742 Masinter.pa@Xerox.COM Format revisited
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:35 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Format revisited
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172535-1480@Xerox>
Summarizing the ballots is slow going. I hope to be done tomorrow and to
mail out some revisions.
Below is a minor revision of the style sheet which incorporates a couple
of suggestions.
Note that the hardcopy of the issues to x3j13 (and the internal copies I
deal with) have font and paragraph control, but I have no simple way of
mailing them out in that form. However, I'd suggest you not worry about
formatting or grinding of paragraphs.
!
Format for proposals to "clean up" Common Lisp.
Revision 9 - 4-Jun-87
>>Replace the text in italics (double inverted angle-brackets). Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.<<
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION. .<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category: >>One or more of: CLARIFICATION - proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE - Proposal for an
incompatible change to the language. ADDITION - Proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission, and author and date of
subsequent revisions.<<
Problem description: >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale: >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal? How much implementation effort is required? Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code? To what extent can the process be
automated? how?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<
∂04-Jun-87 1742 Masinter.pa@Xerox.COM AREF-1D (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:58 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172558-1481@Xerox>
Status: Ready for release.
I made the edits before seing Kent's revision, so I went ahead and
merged his version and mine. I will mail this version out to X3J13 next
week (unless I hear objections.)
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
4-Jun-87, Version 3 by Masinter (very minor editorial
work)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying arity.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF which allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators which allow users to exploit that order. ROW-MAJOR-AREF is
a useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations which already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something which they already have
inefficient access to.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee supports this enhancement.
∂04-Jun-87 1742 Masinter.pa@Xerox.COM Merging of committees
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:27:46 PDT
Date: 4 Jun 87 17:27 PDT
Sender: Masinter.pa@Xerox.COM
Subject: Merging of committees
To: cl-cleanup@Sail.stanford.edu
From: Larry Masinter <Masinter.PA@Xerox.COM>
Message-ID: <870604-172746-1483@Xerox>
On the subject of the possible merger of the cleanup committee and the
error or compiler committees:
I am very much opposed to merging other committees in with the Cleanup
Committee. Even if there is substantial, or even total, overlap of the
committees (e.g., even if everyone on the Compiler Committee is a member
of the Cleanup Committee), the committees have different charters, sets
of issues, etc.
If the Error committee needs some help and the compiler committee needs
some new members, we individually can try to help fix those things.
I also am opposed to taking smaller issues which rightfully belong to
those other committees and putting them thru cl-cleanup.
For example, I am opposed to the CLEANUP committee releasing
Ignore-errors. If Kent thinks it is a good idea to get IGNORE-ERRORS
out, then let that be the report and proposal of the Error committee.
Kent can even report that the Cleanup committee likes the idea, but it
should come as a report and recommendation of the error committee.
I would like to see separate committees (again, even if they
substantially or totally overlap with this one) deal with the issues of
compilation and declarations, the issue of signalling and also the
myriad set of changes where "is an error" might turn into "signals an
error" and where "signals an error" might turn into "signals a FROB
error".
I'm willing to join the error committee and the compiler committee if
its necessary to help get them off the ground or they seem to lack
critical mass, although I'm not yet convinced that it is necessary.
Larry
∂04-Jun-87 1856 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 18:56:05 PDT
Date: 4 Jun 1987 18:55-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 4-Jun-87 18:55:20.MATHIS>
Larry, I just sent you a set of mailing labels for x3j13 as you
requested. They should come by express mail on Friday.
To all of the committee -- keep up the good work.
Bob
∂04-Jun-87 1925 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 19:25:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164454; Thu 4-Jun-87 22:24:02 EDT
Date: Thu, 4 Jun 87 22:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870604-172558-1481@Xerox>
Message-ID: <870604222355.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Change "arity" to "rank" to be consistent with standard Common Lisp
terminology. Otherwise fine.
∂04-Jun-87 1933 KMP@STONY-BROOK.SCRC.Symbolics.COM Merging of committees
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 19:32:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164465; Thu 4-Jun-87 22:31:13 EDT
Date: Thu, 4 Jun 87 22:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Merging of committees
To: Masinter.PA@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870604-172746-1483@Xerox>
Message-ID: <870604223106.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 4 Jun 87 17:27 PDT
From: Larry Masinter <Masinter.PA@Xerox.COM>
... I am opposed to the CLEANUP committee releasing IGNORE-ERRORS.
If Kent thinks it is a good idea to get IGNORE-ERRORS out, then let
that be the report and proposal of the Error committee. Kent can
even report that the Cleanup committee likes the idea, but it should
come as a report and recommendation of the error committee. ...
I disagree. The Error Committee is responsible for preparing a complete
proposal. The Cleanup is responsible for making minor patches. This is a
minor patch which is contingent on the Error Committee -not- doing something.
It would be inappropriate for the Error Committee to make conflicting
recommendations. It is not inappropriate for two groups with (as you
yourself said) different goals to make conflicting recommendations.
I completely agree that the committees should not be merged. Although
there is a gray area in all of this where X3J13 adopts various proposals
of other committees and it may be appropriate for the Cleanup committee
to then take over the job of minor corrections to what at that point
amounts to a normal part of the language. We can cross that bridge when
we come to it, though; it's certainly no relation to what's going on at
this point in any of the subcommittees I know of.
∂05-Jun-87 1808 Masinter.pa@Xerox.COM FORMAT-OP-C (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:08:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:05:51 PDT
Date: 5 Jun 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: FORMAT-OP-C (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-150551-2556@Xerox>
I'm not sure it wouldn't be simpler to make the use of ~C on characters
with non-zero BITS (and FONT?!) an error, rather than attempting to
leave it unspecified. I suppose if we can get up a vote to remove BITS
and FONT from the standard, it is moot.
The discussion of the stream-dependent behavior confused bytes with
characters in an unfortunate way. I rewrote that part of it to be what I
believe the truth is; I'm not sure if you agree, however. My notion was
that write-char always writes a single character; writing a
single-character causes multiple bytes to be written. However, a
subsequent read-char of the same stream should produce EQL characters as
were given to write-char. The only thing which is
stream/operating-system dependent is the mapping of characters to bytes.
When I thought about *that* some more, I decided it was really a
clarification about WRITE-CHAR and not about FORMAT ~C, so I moved the
whole paragraph about clarifying WRITE-CHAR to the discussion section.
This proposal is now very short.
!
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Versions 2,3 by Pitman (merge in suggestions)
5-Jun-87, Version 4 by Masinter, minor copy-editing
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".
Since the behavior of ~A is also vague on characters (a separate
proposal addresses this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Test Case:
(EQUAL (FORMAT NIL "~C" #\Space) " ")
Rationale:
This was probably the intent of the Common Lisp designers.
It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as a
simplification.
Discussion:
The cleanup committee supports this clarification.
The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
It may be necessary to clarify that WRITE-CHAR puts only one character
on its argument stream, such that a subsequent READ-CHAR of the same
file would read only one character. (Of course, in some operating
systems or for some devices, WRITE-CHAR of a single character might
cause multiple bytes to be written, substituted, escaped, quoted or the
like.)
∂05-Jun-87 1809 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:08:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:30:08 PDT
Date: 5 Jun 87 15:30 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 22 Apr 87 15:14 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-153008-2585@Xerox>
I think the reason that ASSOC-IF, RASSOC-IF and friends do not have :KEY
arguments is that ASSOC-IF is equivalent to FIND-IF :KEY #'CAR and
RASSOC-IF is FIND-IF :KEY #'CDR. That is, the way I think of these
functions, they already have a KEY argument, it is just that the KEY is
already implicitly specified by the function name.
I don't see any substantial advantage of expressiveness in this
proposal.
∂05-Jun-87 1809 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:09:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 16:10:52 PDT
Date: 5 Jun 87 16:10 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-161052-2627@Xerox>
I made the discussion less wishy-washy by saying we rejected disallowing
NIL. I made some edits to fix typos various people pointed out. I fixed
the "grinding".
Status: Ready for release.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL. That is:
If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered but rejected a proposal to exclude NIL
as a legal indicator. It might catch some errors, but is otherwise an
odd restriction.
The cleanup committee supports this change.
∂05-Jun-87 2113 KMP@STONY-BROOK.SCRC.Symbolics.COM Sigh -- More procedure
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87 21:12:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 165549; Sat 6-Jun-87 00:12:11 EDT
Date: Sat, 6 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sigh -- More procedure
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870606001157.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sorry for the length of this message. It treats an issue which
I thought we'd settled before when Fahlman edited a proposal and
forgot to change its status back to internal, but in my view that
agreement has been violated again an I want to re-open the issue:
My votes are significantly based on the wording of a proposal, not just
their spirit. My guess from their behavior is that many of the others on
this list do likewise. To me, no other choice is possible because this
same rigor is the manner in which CLtL gets interpreted by users and
we accept the fact that every word and punctuation mark could potentially
make a difference.
Earlier this week, I allocated a long evening to carefully re-read all
the relevant mail leading up to the proposals upon which we were asked
to vote. I allocated this time at your request, believing that this was
the final vote and that extreme care was in order. Now you've changed
the proposal and marked some things ready for release and/or falsely
claimed that the cleanup committee endorses this proposal, which in fact
the cleanup committee has not seen.
When I worked on the student newspaper at MIT, we had a policy that we
didn't reply to letters to the editor; the reason was that the paper
always had the opportunity to get in the last word and this wasn't fair
in a forum which was supposed to promote open discussion. Likewise, we
have an informal rule that the moderator at X3J13 meetings should not
feel free to interject comments in between designating queued speakers
-- since he obviously has an unfair opportunity to say more than is
appropriate. I think it would be useful if we could agree that the
moderator here should follow the same conventions as everyone else in
either not being able to change things at the last minute.
I'm willing to be very liberal in my definition of "the last minute". I
consider that the line was drawn when you yourself said we were making a
final vote and that if people had been hesitating that this was the time
they should say something. I think it is inconsiderate for you to then
make further changes that cause me to feel compelled to spend more time
when I've already gone for broke on my budgeted time at your own
suggestion. I feel that since you have the last contact with the documents
between now and when they are seen by X3J13, that you have a moral
obligation to resist changing them in that interval or to explicitly admit
that another full round of voting is in order.
I was very hesitant to send out my change to AREF-1D and FORMAT-OP-C
proposals at the last minute, but it seemed clear that the vote was not
going to favor the existing versions so there seemed little harm in getting
an early start on the next voting cycle. In fact, even after making all
the desired changes, I carefully marked both of these to have been approved
only on previous passes so that people's votes would not be misconstrued.
This kind of care may seem silly, but I believe it to be important.
I would not have been and will not be disturbed if neither AREF-1D nor
FORMAT-OP-C is presented to X3J13 due to our having had too little time
to review the most recent proposals internally and re-vote.
I want it clear that I have expressed no opinion on:
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
FORMAT-OP-C (Version 4)
If either of these documents is distributed to X3J13 prior to my having
expressed an opinion that they are acceptable in their current form, I
will be upset. [If it is possible for me to accept either or both in the
current form, I'll try to do so to minimize work for all, but I can't
guarantee that.]
By the way, the top of your message about KEYWORD-ARGUMENT-NAME-PACKAGE
says:
``I made the discussion less wishy-washy by saying we rejected disallowing
NIL. I made some edits to fix typos various people pointed out. I fixed
the "grinding".''
In fact, you changed more than just the "Discussion" field. You changed
the Proposal field. I'm sure you meant to use the term generically and not
to specifically mislead me into looking only in the Discussion field to
see what you'd changed, but perhaps this illustrates why every word is so
important to me. One little difference (eg, the difference between "discussion"
and "Discussion") can really have a big effect.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM Re: Sigh -- More procedure
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:45:45 PDT
Date: 5 Jun 87 21:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Sigh -- More procedure
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sat, 6 Jun 87 00:11 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-214545-2882@Xerox>
I'm sorry Kent. In my rush to get things out to X3J13 and to respond to
the rather massive number of minor typos and corrections and remarks
that I recieved, I've been a bit sloppy about recording which sections
got edited in response to which remarks. One problem is that, as you say
yourself, people had been hesitating to say anything about proposals now
open up (at the last minute) with lots of comments on them; in many
cases, they are relevant and useful comments, and the only reasonable
thing to do is to address the comments in the proposal.
I will say that I don't (and didn't) intend to release documents to
X3J13 without there being some opportunity for objections by this
committee.
The "the cleanup committee endorses this ..." statements are of course
provisional. However, if we want to say that we endorse something by
consensus then I need to write it in the proposal itself. If the
proposal says "FOO and JOE like this proposal." and then we all agree,
and I edit it to say "we all agree", then, by your own rules, I'd have
to send it out again for yet another ballot since the wording changed.)
I think we have a little more flexibility about wording than was
available CLtL because the wording of these proposals are in fact
subject to the interpretation of the committee that actually writes the
standards document. That is, we're specifying intent and not exact
wording.
I will be more careful identifying the changes to proposals, and my use
of "Ready for release". (I don't expect to send out any documents to
CL-CLEANUP with the annotation "Ready for release" because, if you've
already seen it and voted on it, then I don't need to send it out again,
do I?)
I'm finally done going through all of the ballots and suggestions and
what have you. I will mail out a new status report shortly, and also
some revised versions of some of the proposals.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:48:23 PDT
Date: 5 Jun 87 21:48 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Message-ID: <870605-214823-2885@Xerox>
(This was prepared before Kent's angry note. I'm a little reluctant to
mail it out now, but I don't know what to do with it. I made the edits
in response to Kent's question, as well as changing the case of the lisp
words, changing revision to version, etc. I don't remember all of the
edits, but I spent quite a while on it.)
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The previous version got lots of yes ballots. Any objections to this
one?
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (Steele p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Problem Description:
The interaction of ADJUST-ARRAY and displacement is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced to B before
the ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :INITIAL-ELEMENT. The use of :INITIAL-CONTENTS
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before and after the call (A is displaced to B
before the call, and the :DISPLACED-TO argument of ADJUST-ARRAY either
is ommitted or is B.) The dimensions of A are altered, and the contents
rearranged as appropriate. If :DISPLACED-INDEX-OFFSET is not specified
in the ADJUST-ARRAY call, it defaults to zero; the old offset is not
retained.
(4) A is displaced to B before the call, and is displaced to C after the
call. As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it
defaults to zero; the old offset (into B) is not retained.
(5) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :INITIAL-ELEMENT. However, the use of
:INITIAL-CONTENTS causes all old contents to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z,
and array Y is altered by ADJUST-ARRAY, array X must now refer to the
adjusted contents of Y. This means that an implementation may not
collapse the chain to make X refer to Z directly and forget that the
chain of reference passes through array Y. (Cacheing techniques are of
course permitted, as long as they preserve the semantics specified here
and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here. Others
may do something random. [See discussion below.]
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
The cleanup committee supports this clarification.
Moon pointed out that the Symbolics system currently does this, except
for case (5) above. The Symbolics system never copies the contents of B
in this case; all elements are taken from the :initial-element. However,
the behavior in the proposal seems as justifiable to him, and the
cleanup committee decided to stick with the proposal as described above.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM AREF-1D (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:52:52 PDT
Date: 5 Jun 87 21:52 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215252-2889@Xerox>
Besides changing arity-> rank and various whichs to thats, I think I
probably made some other minor edits, but didn't intentionally change
the meaning. However, I do remember trying to soften the feeling that
you had to know and want MacLisp's LISTARRAY and FILLARRAY for this to
be a good idea, and to take the blow-by-blow of who liked what in
previous versions out of the discussion. Note that the issue is still
called AREF-1D even those the proposal is ROW-MAJOR-AREF.
Status: Ready for release?
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial work)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee supports this enhancement.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM proposal format (version 10)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:54:55 PDT
Date: 5 Jun 87 21:54 PDT
From: Masinter.pa@Xerox.COM
Subject: proposal format (version 10)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215455-2893@Xerox>
This version incorporates some minor comments.
!
Format for proposals to "clean up" Common Lisp.
Version 10 - 5-Jun-87
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION. .<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description: >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale: >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal? How much implementation effort is required? Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Cost of non-adoption: >>How serious is it if nothing is done? <<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code? To what extent can the process be
automated? How?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<
∂05-Jun-87 2210 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:57:51 PDT
Date: 5 Jun 87 21:57 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
Message-ID: <870605-215751-2896@Xerox>
I think all I did was minor formatting changes (e.g., Defun => DEFUN,
Revision -> Version, SEF -> Fahlman, etc.) although it was a long time
ago today and I'm not 100% sure.
Status: Ready for release?
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: Omission.
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
Flet.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.
∂05-Jun-87 2235 Masinter.pa@Xerox.COM Re: proposal format (version 10)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:35:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:19:34 PDT
Date: 5 Jun 87 22:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: proposal format (version 10)
In-reply-to: Masinter.pa's message of 5 Jun 87 21:54 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870605-221934-2920@Xerox>
The "proposal format" I mailed looks much better with fonts rather than
in plain ascii. However, since we prefer proposals in ascii rather than
formatted (or at least, I do) I am going to reformat it so that it looks
good with a simple fixed-pitch font, no italics, etc.
(I'm sorry to say that I looked at the without-formatting version for
the first time when I got the bounce back from the arpanet.)
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:38:06 PDT
Date: 5 Jun 87 22:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-223806-2928@Xerox>
This one had just revision -> Version and KMP -> Pitman.
Status: ready for re-release! No ? about it.
!
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 at committee meeting 15-Mar-87
Version 3 Masinter 15-Mar-87
Version 4 by Fahlman, incorporate Dribble
Version 5 by Masinter, 29-May-87, revert to Version 3
Version 6 by Masinter, 5-Jun-87, minor formatting
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:42:38 PDT
Date: 5 Jun 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224238-2931@Xerox>
This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".
Status: Version 3 released. Ready for re-release! (no ? about it).
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter (normalize format) 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee supports this clarification.
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:43:39 PDT
Date: 5 Jun 87 22:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224339-2934@Xerox>
The subject of the previous message was wrong (it said Revision 3)
This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".
Status: Version 3 released. Ready for re-release! (no ? about it).
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter (normalize format) 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee supports this clarification.
∂05-Jun-87 2349 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 23:49:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:28:48 PDT
Date: 5 Jun 87 23:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870605-232848-2962@Xerox>
Gregor said in his ballot that comments would follow, but I can't find
them. Did I miss them? I saw some notes about a more general facility
for accessors and constructors of lexical environments on the CLOS
mailing list, so I hoped I was on the mark by adding that to the
discussion section.
Kent asked that NIL be explicitly allowed for the null lexical
environment. I put that in.
Version 2 got lots of yes ballots.
Status: Ready for release?
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter (from Steele
list)
... 7-Apr-87, merged with other environment
argument issues
Version 2 29-May-87, by Masinter, extracted again
Version 3 5-Jun-87, by Masinter.
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂06-Jun-87 0000 Masinter.pa@Xerox.COM ***READ ME FIRST ***Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 23:59:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:52:39 PDT
Date: 5 Jun 87 23:52 PDT
From: Masinter.pa@Xerox.COM
Subject: ***READ ME FIRST ***Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870605-235239-2975@Xerox>
This is not meant to go outside of this committee, although it will be
the source for a status report. My belief is that, while we may want to
mail out proposals ahead of time, there is no need to mail out the
status report early, we might have more to report by the meeting anyway.
**** NOTE ***** I intend to mail the proposals marked with a * (Ready
for release?) to mail to X3J13 by Wednesday of next week unless I hear
some objection. (I think I'm a little upset that Kent is got so mad at
me.)
If there is one issue we should debate about between now and the
meeting, I think it is FUNCTION-TYPE. We seem to have some agreement on
the core issue, and some disagreement on exactly how to proceed over the
issue of making FUNCALL (and MAPC) not take symbols. I think this is
one where we should bring the debate to the whole X3J13 once the issues
are laid out.
Normally, before I send one of these out I double check all of the
entries against all of the mail files to make sure that I've left
something out. However, I'm tired and its late, and I've only checked
them out to GET-SETF-METHOD-ENVIRONMENT.
In this document: EB = Benson, GLS = Steele, PC = Pavel Curtis, KMP =
Kent Pitman SEF = Scott Fahlman
[name/initials] position => person identified by name/initials voted
position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.
Withdraw = Place on hold pending resolution of comments already
received.
Proposal format (Version 10)
Needs re-formatting for non-fonted ascii
ready for release otherwise?
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Comments & edits after ballot.
Ready for release?
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
comments from Moon, JonL, SEF against current form
[EB, PC, SEF] Withdraw
Not ready for release
* AREF-1D (Version 4/5-jun-87)
(Add a new function for accessing arrays with row-major-index)
[all] Version 2 release as ROW-MAJOR-AREF
Ready for release?
* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
(Extend ASSOC-IF, etc. to allow :KEY)
[EB, GLS, KMP] Release as is
[LMM] ASSOC-IF has CAR for KEY?
Ready for release?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
* COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
Version 3 released.
Version 6 ready for re-release!
* DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 ready for re-release!
* DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Ready for release?
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
[EB, GK] DO-SYMBOLS:ALLOWED
[PC, Moon, LMM] something like :ADD-KEYWORD
In discussion, not ready for release
ENVIRONMENT-ARGUMENTS (Version 1)
Separated into other proposals.
Withdrawn.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Not yet submitted.
* FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Ready for release?
* FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
Version 3 released.
Version 4 ready for re-release.
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
* FORMAT-OP-C (Version 4/ 5-Jun-87)
(What does ~C do?)
Ready for release?
FUNCTION-TYPE (Version 4/ 29-May-87)
(Change definition of FUNCTIONP, function type ...)
[EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
addressed
[KMP] break in two, so I could
support the half I like and only grump about the parts I don't
want stronger warning
[SEF] 2-option, 3-option version
GET-SETF-METHOD-ENVIRONMENT (Version 3, 5-jun-87)
(Environment argument for GET-SETF-METHOD)
[EB, GLS, PC, Moon, SEF] Release as is
[GK] Ballot says comments follow, but no comments?
[KMP] NIL as null lexical environment
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
* IF-BODY (Version 5, 29 Apr 87)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
While EB, PC, Moon voted to wait for a version that KMP and SEF
agreed was fair, SEF said 5 was fair enough.
Ready for release
IGNORE-ERRORS (Version 4, 29-May-87)
[EB, LMM, PC, Moon] Wait for error proposal
[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...")
LMM wants KMP to submit as proposal from Error committee
IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
Version 3 Released
Version 4 ready for re-release after Revision->Version
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5/5 Jun)
[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments
MACRO-FUNCTION-ENVIRONMENT
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
PATHNAME-STREAM (Version 2)
[EB, GK, PC, Moon, SEF] Release as is
PATHNAME-SYMBOL (Version 2)
[GLS, PC, Moon, KMP, SEF] Release as is [eb] against, want minority
view (needs formatting)
Moon " cover every argument that is called pathname, filename, file, or
new-name
and leave the rest of the ambiguities for another proposal?"
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal
PRINC-CHARACTER (Version 3)
Mailed by KMP 29-Apr-87.
Ready for release?
PROCLAIM-LEXICAL (Version 1)
In discussion
Some progress
Need volunteer to merge comments into new version
PROMPT-FOR (Version 1)
Agreed to be controversial
[EB, PC, Moon, SEF] Withdraw
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not yet submitted. [PC, SEF] (PUSH FIRST SECOND)
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
[EB] Unchanged [PC, KMP, SEF] Undecided
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
[EB] Release as is [pc, KMP] no, remove bits & font, fuller character
proposal
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Withdraw?
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal.
SPECIAL-FORM-SHADOW
Is it OK to shadow a special form with FLET, LABELS?
Not yet submitted
(From ENVIRONMENT-ARGUMENTS)
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
Notes from Moon
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues.
∂06-Jun-87 1412 RPG A Hole in Common Lisp
To: cl-cleanup@SAIL.STANFORD.EDU
Consider the nature of arguments to functions. In Common Lisp we have
these two notions: positional arguments and named arguments. In the first
case values are associated with variables depending on the positions of
passed arguments. In the latter case, the binding happens depending on
the names of the arguments, which are passed along with the arguments.
For example:
(defun f (x y &key a b) ...)
(f 1 2 :b 3 :a 4)
X and Y are positional, and A and B are named.
There is a second pair of notions: required arguments and optional arguments.
Does Common Lisp have all of the combinations of these notions?
| positional | named |
-------------------------------
required | yes | no |
-------------------------------
optional | yes | yes |
-------------------------------
It doesn't seem so. Keyword arguments combine named and optional.
Also there is no way to have a function with both required keyword and
truly optional positional arguments.
Suppose someone writes
(defun f (x y &optional a b &key foo bar baz ola)
(list x y a b foo bar baz ola))
and this form is evaluated:
(f <a1> <a2> <a3> <a4> <a5> <a6> <a7> <a8>)
The binding of the variables in the function definition goes like this:
x is bound to <a1>, y is bound to <a2>, a is bound to <a3>, and b is
bound to <a4>. Now we lift our heads from the sand and look at what
<a5> is. It should be one of :foo, :bar, :baz, or :ola. Now suppose
we had written:
(f 1 2 :foo 4 :bar 5 :baz 6)
Did the user intend for a to be bound to :foo, or did he intend for
a and b to not be supplied?
Here is an off the wall proposal for lambda expressions; it includes
Moon's proposal for non-keyword package symbols to be names of arguments:
(lambda ({var}*
[&optional {var | (var [initform [svar]])}*]
[&required-key {var | (name var)}*]
[&rest var]
[&key {var | (name var)} [initform [svar]])}*
[&allow-other-keys]]
[&aux {var | (var [initform])}*])
{declaration | documentation-string}*
{form}*)
where var, initform, svar are exactly as before, and name is the name of
a keyword argument, which can be a symbol in any package. Parsing an
argument list proceeds as follows:
Let nrp be the number of required positional parameters. The first nrp
supplied arguments are paired with the nrp required positional parameters.
The remaining supplied arguments are scanned left-to-right, starting with
scanning for positional optionals. If a supplied argument is EQ to one of
the required named parameters names, the scanning for positional optionals
ends and all unpaired positional optionals are defaulted according to the
lambda-list specification; then named parameter parsing begins. If a
supplied argument is not EQ to any required named parameter name, it is
paired with the next positional optional parameter.
Once the scanning for optional positional parameters has ended, scanning
for named parameters begins. Named parameter parsing is as in current
Common Lisp, except that if, at the end, there are unsupplied
required named arguments, an error is signaled.
The difference between this parsing algorithm and the current Common Lisp
one is that the occurrence of the first required named parameter stops
parsing of positional optionals. Therefore, the only way to pass the name
of required named parameter is as a required positional or required named
argument. Also, if optional named arguments appear to the left of all
required named arguments, they can be taken as positional optionals.
Examples:
(defun f (x y &optional a b &required-key foo bar &key baz ola)
(list x y a b foo bar baz ola))
(f 1 2 3 4 :foo 5 :bar 6 :baz 7 :ola 8)
=> (1 2 3 4 5 6 7 8)
(f 1 2 3 :bar 4 :baz 5 :foo 6 :ola 7)
=> (1 2 3 nil 6 4 5 7)
(f 1 2 :baz 3 :foo 4 :bar 5)
=> (1 2 :baz 3 4 5 nil nil)
(f 1 2 :baz :foo 3 :bar 4)
=> (1 2 :baz nil 3 4 nil nil)
This has the advantage that it could make some things in CLOS easier
to deal with. For example, we could define methods that discriminated
on the names of required named arguments:
(defmethod foo (x y &required-key foo bar) `(foobar ,x ,y ,foo ,bar))
(defmethod foo (x y &required-key baz ola) `(bazola ,x ,y ,foo ,bar))
(foo 1 2 :foo 3 :bar 4) => (foobar 1 2 3 4)
(foo 1 2 :baz 3 :ola 4) => (bazola 1 2 3 4)
(foo 1 2 :foo 3 :ola 4) => error
-rpg-
∂06-Jun-87 1630 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
I regard this issue as a put-up-or-shut-up affair. I prefer
the formulation that states that APPLY and FUNCALL take functions,
and you have to coerce symbols and lambda-expressions to be functions
before you can APPLY or FUNCALL them to more lenient formulations.
If we do not go with this formulation, then I would say an
important design criterion of the cleanup is:
Changes that introduce or retain inconsistencies which confuse new users
and which complicate the rules of the language are preferable to changes
that cause old programs to stop working.
I think Common Lisp is so messed up that the cleanest change to
function types will not effect major improvements. Our position
with respect to EuLisp will be more difficult.
Put up or shut up: I don't care which you choose.
-rpg-
∂06-Jun-87 1802 FAHLMAN@C.CS.CMU.EDU A Hole in Common Lisp
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jun 87 18:02:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 6 Jun 87 21:01:40-EDT
Date: Sat, 6 Jun 1987 21:01 EDT
Message-ID: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: A Hole in Common Lisp
In-reply-to: Msg of 6 Jun 1987 17:12-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Of course, it's too late for Common Lisp -- this would be a VERY
incompatible change for no very good reason. And, of course, you can
get the effect of a required keyword argument by signalling an error in
the init form. We could provide some conventional function for
signalling this error and CLOS could recognize this and treat that arg
as required.
Even if I were designing a new Lisp from scratch, I'm not sure that I
would want to fill in the fourth box in your matrix. By-name arguments
are for functions that have so many arguments that you can't remember
the order, or so many that it is convenient just to type in the two or
three you need and not the twenty you don't need. But if the by-name
arguments are required, you have to type them all. Furthermore, you
must remember them all (or look them up to make sure you haven't
forgotten one), and in that case you may as well enter them in the
canonical order.
Even if I wanted to mix positional and named args in a single function,
I don't like your way of doing it -- it seems treacherous to me. If the
value of certain arguments to a function happen to match the named
arguments, things get interpreted in an unintended and very mysterious
way. This would only be a good scheme if there were absolute separation
between the space of legal arguments and the space of arg names. We
would have to go back to saying that all keywords must be keywords, and
we would also have to eliminate the practice of using keywords for other
things. Or else we would have to create a new kind of object that is
reserved for use in arg names.
I have sometimes thought that if I were designing a lisp-like language
from scratch, I would leave the question of by-postion or by-name
arguments to the caller of a function. He's the one who can decide
whether he wants to remember the order of arguments or to do some extra
typing. A lambda would have the following simple form (setting aside
&rest and &more arguments for now, and flushing &aux, which was a
mistake from the start):
(lambda ({var | (var intiform) | (var initform svar) }* )
declarations, docs, body, etc. )
Variables with no initform are required. They need not be at the head
of the list.
There are two forms of function calling, postional and by-arg-name
either of which can be used on any function. They need to be
syntactically distinguished somehow. I'll use square brackets to group
the name/argument pairs in the latter -- this might be a read macro that
turns into some three-element list with a reserved token in the car.
(function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)
(function-name [nameX argX] [nameY argY] ...)
The latter form says to look up the argument names at the time of the
call and rearrange the call into the order the function is expecting;
cacheing of this step is encouraged. The order of evaluation of a
function's args would be explicitly unpredictable in this language, so
the rearrangement is legal and not difficult.
Then the function gets called, unsupplied args get their initforms
evaluated, and if any of the required args does not have a value
assigned, an error is signaled. If the lambda list has any optional
args before a required arg, the only way NOT to supply a value for the
optional args is to use the by-name form of call.
One can imagine versions of this in which the caller can mix positional
and named args -- some arguments and then some bracketed pairs -- but if
this is allowed, one would have to worry about what happens if the same
variable gets a positional value and a by-name value. Signal an error,
I guess, or say that the result is indeterminate.
-- Scott
∂07-Jun-87 0826 FAHLMAN@C.CS.CMU.EDU Rules
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 08:26:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 11:26:18-EDT
Date: Sun, 7 Jun 1987 11:26 EDT
Message-ID: <FAHLMAN.12308615853.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Rules
I think that KMP is a bit out of line in complaining that he has now
blown his entire time budget for this stuff and that new versions are
somehow out of line. When problems are spotted, even late in the
process, they have to be fixed, and then we need another round of
consideration. Things only become final if we manage to come up with a
version that nobody objects to, or if we explicitly agree to disagree.
For those of us who insist upon having a say on the final form of every
issue, it is impossible to set an a priori limit on the time that will
be required. We need some balance between the power of the chairman to
ram through a lot of unexamined changes at the last minute and the power
of any one member to block progress because he has some other commitments.
However, I agree with KMP that Masinter is at fault in several areas.
The most serious problem is that he has greatly increased the amount of
time the rest of us must spend in considering new versions by changing
things in gratuitous and unrecorded ways. Larry also put a few of his
own ideas into the new versions without any prior discussion -- a
practice he used to complain bitterly about when I was chairman.
Finally, he has thrown everyone into a panic by making it look like a
modified proposal might go out with a statement of support by people who
stated support for the previous version and not necessarily the current
one.
-- Scott
∂07-Jun-87 1150 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87 11:50:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166143; Sun 7-Jun-87 14:50:04 EDT
Date: Sun, 7 Jun 87 14:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870607144946.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 06 Jun 87 1630 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
... Changes that introduce or retain inconsistencies which confuse new
users and which complicate the rules of the language are preferable to
changes that cause old programs to stop working.
I think Common Lisp is so messed up that the cleanest change to
function types will not effect major improvements. Our position
with respect to EuLisp will be more difficult. ...
I disagree with your claim that a change to the function types alone will
not make a major improvement in the language.
We can define any function to do anything we want. That in itself does
not make the language inconsistent. There is nothing inconsistent about
defining the functions FUNCALL and APPLY to take arguments which are
coercible to functions, especially if you also make it clear that you
can put things in function cells which are coercible to functions.
This is no more unreasonable than allowing any function to coerce its
argument. Consider STRING-DOWNCASE of a symbol, for example.
One of the great powers of types in a language is that you can tell when
you have one that is not quite suitable and define an interpretation for
it. If you require exactly one type as an argument to all functions, you
alienate the whole notion of generic functions and take us into a world
that more resembles CLU, where you need one function for every type.
If all we did was fix the types and not fix the business about what can go
in the cells or be given to APPLY or FUNCALL, we'd still have a lot.
Consider that if the EuLisp guys don't like our definition of the functions
and want to run EuLisp compatibility in our lisp, they can effectively do:
(IN-PACKAGE "EULISP" :USE "CL")
(SHADOW '(APPLY FUNCALL))
...
(DEFUN APPLY (FUNCTION &REST SPREAD-ARGUMENTS)
(CL:APPLY (THE FUNCTION #'CL:APPLY)
(THE FUNCTION FUNCTION) SPREAD-ARGUMENTS))
(DEFUN FUNCALL (FUNCTION &REST ARGUMENTS)
(CL:APPLY (THE FUNCTION FN) ARGUMENTS))
And as for us, we can do the following to win in theirs:
(IN-PACKAGE "COMMONLISP" :USE "EU")
(SHADOW '(APPLY FUNCALL))
...
(PROCLAIM '(INLINE COERCE-TO-FUNCTION))
(DEFUN COERCE-TO-FUNCTION (FN)
(FLET ((FAIL () (ERROR "Not a function: ~S" FN)))
(TYPECASE FN
(FUNCTION FN)
(SYMBOL (SYMBOL-FUNCTION FN))
(LIST (IF (EQ (CAR LIST) 'LAMBDA)
(EVAL ,LIST)
(FAIL)))
(OTHERWISE (FAIL)))))
(DEFUN APPLY (FN &REST SPREAD-ARGUMENTS)
(EU:APPLY #'EU:APPLY (COERCE-TO-FUNCTION FN) SPREAD-ARGUMENTS))
(DEFUN FUNCALL (FN &REST ARGUMENTS)
(EU:APPLY (COERCE-TO-FUNCTION FN) ARGUMENTS))
Not much code for either side.
The thing which makes this so easy going both directions is the agreement
on making the FUNCTION type something that you can get leverage out
of.
The issue of how you deal with that type in any given function is
interesting, but need not (and I think should not) be intimately tied
up with this much more important issue that we probably can and should
all agree upon.
You might say that this is so little code that we should go the extra
little bit and just agree to make the mechanisms the same, but I don't
think that would be wise. To go further for us would compromise large
bodies of existing code and built-in philosophies about Lisp and what
it can do for them. To go further for the Eulisp guys might compromise
their existing code and their philosophies. I think that either side
has a defensible reason for maintaining their ground and that it is
appropriate to agree not to agree on this issue.
∂07-Jun-87 1259 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 12:52:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 15:51:42-EDT
Date: Sun, 7 Jun 1987 15:51 EDT
Message-ID: <FAHLMAN.12308664162.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 7 Jun 1987 14:49-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I think the issues involved in FUNCTION-TYPE are now clearly drawn and
we may as well settle this whole package one way or the other, rather
than separating the issue into parts, settling the type cleanup now, and
letting the related questions hang in limbo for another six months.
It's a bit frightening to me personally to propose this, since I won't
be at the Boston meeting, but I'd rather have a clear decision in favor
of ANY of the three proposals than to let this hang indefinitely.
It is reasonable to let questions hang if we're waiting for some related
issues to be resolved or if technical work needs to be done (as in
solving the macro problem for Lisp-1) or if people really need time to
study the implications of a proposed change. I don't see any of those
factors at work in the FUNCTION-TYPE issue -- it is a straightforward
question of whether we want to remove some ugly tangles from the
language at the expense of breaking some existing code. This question
is not going to get any easier, and until it is decided we all have to
code defensively.
Shall I attempt to write up FUNCTION-TYPE as a three-option proposal
that can be debated and voted on in Boston?
-- Scott
∂07-Jun-87 1318 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87 13:18:22 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166175; Sun 7-Jun-87 16:17:14 EDT
Date: Sun, 7 Jun 87 16:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308664162.BABYL@C.CS.CMU.EDU>
Message-ID: <870607161700.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I do not believe that all that can be usefully said about FUNCTION-TYPE
has been said. For example, I would like to discuss further this issue
you raised of providing a function to get the original s-expression from
a coerced function (of clean-type FUNCTION). T has such a function.
Its mere presence doesn't make everything ok, but it might contribute
to some overall theory. Before making a proposal, I need to study the
consequences of having it a bit more -- and I have no time to do that
right in the next couple of weeks. The details of this issue could
affect my view on the proposal currently on the table.
For reasons such as this, I feel that it would be premature to bring
FUNCTION-TYPE to the table at this meeting. I'd rather see this brought
to X3J13 only when we were sure we had things carefully thought out, to
preclude wasting valuable time in in-person meetings due to inadequate
preparation. The fact that Steele (and you?) will not be at the Boston
meeting is another good reason to wait.
Let's just keep this one on hold for two more months. I don't see how
that much time can hurt a lot, and I do see how it can help. It's not
like we don't have enough else to keep us all busy in the interim.
∂07-Jun-87 1348 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 13:48:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 16:47:37-EDT
Date: Sun, 7 Jun 1987 16:47 EDT
Message-ID: <FAHLMAN.12308674344.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 7 Jun 1987 16:17-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Well, I'll leave it to the others to decide whether it is reasonable to
delay the whole decision process for several months because you haven't
yet decided what your position is. If several people on the committee
are uneasy about this FUNCTION-TYPE issue because of the points you have
raised (or because of other problems), we should probably wait and
discuss it some more; if it's just you, I don't think you have a veto
either over the proposal itself or over the decision that it's time to
vote on it. (You may, however, have a legitimate parliamentary
objection if the proposal being voted on has not been on the table for a
sufficient time prior to a vote.)
It's possible that this can be discussed in Boston and settled by a
letter ballot shortly thereafter. Unlike most of these "garbage"
issues, I think this one is worth some of our precious face-to-face
time.
By the way, I thought I had told people on Cleanup this, but I guess I
just told certain individuals: I will not be able to be at the Boston
meeting. I had already made plans to be in England when this meeting's
date was settled in Palo Alto. I'd like to be at the meeting, but I
trust the members of X3J13 not to do anything too horrible in my
absence.
-- Scott
∂07-Jun-87 1603 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:02:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:02:22-EDT
Date: Sun, 7 Jun 1987 19:02 EDT
Message-ID: <FAHLMAN.12308698874.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C (Version 4)
In-reply-to: Msg of 5 Jun 1987 18:04-EDT from Masinter.pa at Xerox.COM
This version is OK by me except for the last paragraph of the
discussion. I think you're introducing an entirely new topic in the
offhand comment about READ-CHAR always returning one charater for every
one WRITE-CHAR has written. This might be worth a clarification of its
own, but it shouldn't be introduced here, especially as a
"clarification", which makes it sound like that interpretation is
obvious to the people who endorse FORMAT-OP-C.
Drop the last paragraph?
-- Scott
∂07-Jun-87 1612 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:12:45 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:12:08-EDT
Date: Sun, 7 Jun 1987 19:12 EDT
Message-ID: <FAHLMAN.12308700652.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
In-reply-to: Msg of 5 Jun 1987 19:10-EDT from Masinter.pa at Xerox.COM
This looks good to me.
-- Scott
∂07-Jun-87 1622 RPG Hole
To: cl-cleanup@SAIL.STANFORD.EDU
Actually, I think I wrote things up so that if no one uses &required-key,
everything behaves as before. Possibly there is some definition of
``compatible'' with which I am not familiar such that this behavior is
``very incompatible?''
I suppose if someone wants to not have to remember twenty keywords, they
don't have to use &required-keys.
I ran through the exercise of inventing a new type of object for
names of arguments, but then when I considered the frequency of
this sort of checking and the ways I know type space is divided in
current implementations, it didn't seem worth it.
Of course, if CLOS needs required named arguments for discrimination
(not error signaling) it can be a feature of CLOS lambda-lists
not available in Common Lisp. The syntax of CLOS lambda-lists is an extension
already.
-rpg+
∂07-Jun-87 1630 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:30:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:29:54-EDT
Date: Sun, 7 Jun 1987 19:29 EDT
Message-ID: <FAHLMAN.12308703889.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
In-reply-to: Msg of 6 Jun 1987 00:48-EDT from Masinter.pa at Xerox.COM
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The manual is pretty vague in this area, but my reading of
ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
resulting array is never displaced, even if it had been originally.
That's what we implemented in Spice Lisp, and that's the interpretation
that seems to be consistent with the rest of this proposal (e.g. the rule
that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
than the old index).
So I support the earlier version of the proposal, with the added
clarification that if no :DISPLACED-TO argument is supplied in a call to
ADJUST-ARRAY, the resulting array is not displaced, even if the original
array had been displaced. That is clear, simple, and sufficient in my
view.
It might be argued that a displaced array should remain displaced unless
the user specifically specifies otherwise. I can imagine some
modularity arguments for such a view, though I don't think they are
compelling. If someone strongly prefers this interpretation, I wouldn't
object and would even arrange to fix the CMU code so that we can still
say that public-domain code is available. However, this change will
surprise some people and it should be clearly stated, not hidden in a
parenthetical statement in point 3. Also, we should probably go over
the whole proposal to make it consistent with this change.
-- Scott
∂07-Jun-87 1632 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
I'm sorry I used the word ``inconsistency'' when I meant to use the phrase
``multiplicity of rules.'' To new users, an abundance of rules where one
would seem to be necessary is often viewed by such users as either an
inconsistency in design philosphy among the various parts of the language
or an inconsistency in the sanity of the designers of the language.
I rephrase my cynical design rule:
``Changes that introduce or retain a multiplicity of rules where a single
rule will do are preferable to changes that cause old programs to stop
working.''
-rpg-
∂07-Jun-87 1648 RPG FUNCTION-TYPE and EuLisp
To: cl-cleanup@SAIL.STANFORD.EDU
I said in a message:
``Our position with respect to EuLisp will be more difficult....''
KMP goes on to argue various positions the EuLisp folks might have. I
suppose a reasonable way to proceed is to set up KMP and some other people
to simulate the EuLisp folks and assume positions they might have, and we
can see how well our arguments might apply to those positions, but what I
meant by my remark is that if we moved as far as the cleanest formulation
of the FUNCTION-TYPE issue, that would be seen as an act of good faith on
our part and would cause the two groups to move much closer together and
to proceed with a common design much more easily.
If, for example, we changed Common Lisp to be a Lisp1 dialect, the groups
would merge. By ``position'' I meant negotiation position. I don't expect
this group to understand the process of negotiating with the EuLisp folks,
so there is no point in arguing the merits here.
-rpg-
∂07-Jun-87 1753 FAHLMAN@C.CS.CMU.EDU AREF-1D (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:53:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:53:13-EDT
Date: Sun, 7 Jun 1987 20:53 EDT
Message-ID: <FAHLMAN.12308719055.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: AREF-1D (Version 4)
In-reply-to: Msg of 6 Jun 1987 00:52-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1755 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:55:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:24-EDT
Date: Sun, 7 Jun 1987 20:54 EDT
Message-ID: <FAHLMAN.12308719270.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
In-reply-to: Msg of 6 Jun 1987 00:57-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:55:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:49-EDT
Date: Sun, 7 Jun 1987 20:54 EDT
Message-ID: <FAHLMAN.12308719347.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
In-reply-to: Msg of 6 Jun 1987 01:37-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:56:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:55:26-EDT
Date: Sun, 7 Jun 1987 20:55 EDT
Message-ID: <FAHLMAN.12308719458.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
In-reply-to: Msg of 6 Jun 1987 01:43-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:56:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:56:00-EDT
Date: Sun, 7 Jun 1987 20:55 EDT
Message-ID: <FAHLMAN.12308719561.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
In-reply-to: Msg of 6 Jun 1987 02:27-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂08-Jun-87 0646 gls@Think.COM FORMAT-OP-C (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 06:46:37 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 09:48:58 EDT
Date: Mon, 8 Jun 87 09:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: FORMAT-OP-C (Version 4)
To: Masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870605-150551-2556@Xerox>
Message-Id: <870608094647.1.GLS@BOETHIUS.THINK.COM>
I approve of FORMAT-OP-C:WRITE-CHAR, version 4.
Good work, Larry.
--Guy
∂08-Jun-87 0727 gls@Think.COM Hole
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 07:27:00 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 10:29:36 EDT
Date: Mon, 8 Jun 87 10:27 EDT
From: Guy Steele <gls@Think.COM>
Subject: Hole
To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706072326.AA12046@Think.COM>
Message-Id: <870608102731.4.GLS@BOETHIUS.THINK.COM>
It strikes me that the interaction of &optional and &required-key
arguments is dicey at best. It might be better to allow one or the
other kind of argument but not both in a single lambda-list.
I am also not crazy about the name &required-key; it is too obviously
the result of leaning over backwards to accommodate history.
An aesthetically more pleasing design that deals with both objections
is simply to use the existing keywords &key and &optional, with the
extension that &optional may occur *after* &key if desired. That is, it
is still true that each of &optional and &key may appear at most once in
an argument list, but they may appear in either order. Thus &key marks
the transition from by-position to by-name, and &optional marks the
transition from required to optional. One may then have either of two
patterns:
(defun blah (x y z &optional p q r &key a b c) ...)
----- ----- -----
| | |
| | optional named
| optional positional
required positional
(defun blee (x y z &key p q r &optional a b c) ...)
----- ----- -----
| | |
| | optional named
| required named
required positional
Thus required named and optional positional cannot be mixed,
and no new keyword is needed. The only unfortunate aspect of
this proposal is that it is incompatible with previous practice.
Currently
(defun blaw (x y z &key a b c) ...)
treats a, b, and c as optioal named parameters, whereas this
new proposal would treat them as required.
--Guy
∂08-Jun-87 0802 FAHLMAN@C.CS.CMU.EDU Hole
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 08:01:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 11:00:42-EDT
Date: Mon, 8 Jun 1987 11:00 EDT
Message-ID: <FAHLMAN.12308873322.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Hole
In-reply-to: Msg of 8 Jun 1987 10:27-EDT from Guy Steele <gls at Think.COM>
Well, I was wrong about this being incomaptible, but I still don't see
what problem you two think you are solving, unless an empty box in the
matrix of possible language constructs is considered to be a problem.
Does this make life any better for the user of Common Lisp?
-- Scott
∂08-Jun-87 1128 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 11:28:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 87 11:25:16 PDT
Date: 8 Jun 87 11:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870608-112516-4180@Xerox>
This issue was just submitted by Jim Kempf. I made some minor edits to
his submission (e.g. fundef => function definition) but it is otherwise
as submitted.
My comments:
I think the test case needs to be fixed up so that it can stand alone
(i.e., be a fragment of code that could, for example, become a part of a
diagnostic suite).
Does this have any justification other than the Common Lisp Object
System? (I think it does, but they aren't mentioned here.)
Other than that, I think it looks OK. What do you think?
!
Issue: SHARP-COMMA-SPECIAL-FORM
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: Version 1 submitted 6/6/87, James Kempf.
Problem description:
The specification of #, (load time evaluation) in Common Lisp does not
provide a means of generating code using macros which can perform load
time evaluation within embedded forms. Load time evaluation at the top
level is possible using (EVAL-WHEN (LOAD) ... ), but there is no way
arrange for a form generated by a macro to be evaluated at load time
because #, is a reader macro and code generated by macros is not
processed by the reader.
Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL):
When interpreted or compiled in memory, LOAD-TIME-EVAL evaluates its
argument immediately. When being compiled as part of a file compilation,
LOAD-TIME-EVAL arranges for its argument to be evaluated when the file
is loaded. LOAD-TIME-EVAL can be used anywhere, and is not restricted to
being a top level form, nor to code being processed by the reader.
Test Case:
(defmacro call-method (spec &rest args)
`(apply
(load-time-eval
(load-time-look-up-method ,spec))
,args)))
This macro generates code which applies a function which is determined
at load time. It is a summary of some more complex code in the
CommonObjects object-oriented language extension built on the Common
Lisp Object System.
Rationale:
Currently, there is no way to arrange for load time evaluation within
macro generated code. This capability is required for object-oriented
extensions of Common Lisp, since often neither the name nor the function
definition object is known until load time. It is particularly useful
for optimizing calls to superclass methods.
Current practice:
Currently, every version of Common Lisp is required to implement
compiler hooks for #, so the primitives for implementing LOAD-TIME-EVAL
should exist.
Adoption Cost:
The cost to implementors should be relatively slight, considering
primitives for implementing #, can be resued. Many implementations of
Common Lisp may have LOAD-TIME-EVAL available as public domain code, if
they done it for Portable Common Loops.
Cost of non-adoption:
Optimization of CALL-NEXT-METHOD in the Common Lisp Object System will
be implementation dependent, and other languages built on the metaclass
kernel wanting to optimize calls to superclass methods will have no
specified, portable way of doing so.
Benefits:
Optimization of calls on superclass methods in the Common Lisp Object
System will have a portable hook, which will make transporting code
easier. If the problem is left as it is, each vendor could solve the
problem differently, encouraging nonportable code.
Conversion Cost:
Extremely low. Most users will be completely unaffected.
Esthetics:
The proposal fills a hole in the spectrum of alternatives for achieving
load time evaluation. Currently, code which is read by the reader can
arrange for it to be done, as can top level code, but embedded code
cannot.
Discussion:
There seems to be little disagreement on this, as far as can be
determined at this date. The Portable Common Loops implementation
encourages vendors to add this, to facilitate calling superclass methods
directly, and there has not been any negative reaction so far. It will
certainly help make the Common Lisp Object System easier to implement,
and easier to extend.
∂08-Jun-87 1240 RPG Hole
To: cl-cleanup@SAIL.STANFORD.EDU
The only problem that could be solved by filling in this hole is to
give people a way to supply fewer than all of the optional positionals
while supplying some of the named arguments. My suggestion doesn't help
with that much.
As I've mentioned before - but as I know I must mention again - the effect
of this might have some relevance to CLOS in which it might be useful (the
CLOS folks have not yet decided) to discriminate on the names of named
arguments.
For example, writing this
(defmethod f ((x c1) (y c2) &required-key foo bar) <code1>)
(defmethod f ((x c1) (y c2) &required-key baz ola) <code2>)
is simpler to understand than this
(defmethod f ((x c1) (y c2)
&key (foo nil foo-p) (bar nil bar-p)
(baz nil baz-p) (ola nil ola-p))
(cond ((and foo-p bar-p) <code1>)
((and baz-p ola-p) <code2>)))
And when one writes instance initialization code in CLOS, you will be
writing lots of code like this.
-rpg-
∂08-Jun-87 1342 FAHLMAN@C.CS.CMU.EDU Hole
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 13:42:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 16:41:08-EDT
Date: Mon, 8 Jun 1987 16:40 EDT
Message-ID: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Hole
In-reply-to: Msg of 8 Jun 1987 15:40-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
The only problem that could be solved by filling in this hole is to
give people a way to supply fewer than all of the optional positionals
while supplying some of the named arguments. My suggestion doesn't help
with that much.
As I've mentioned before - but as I know I must mention again - the effect
of this might have some relevance to CLOS in which it might be useful (the
CLOS folks have not yet decided) to discriminate on the names of named
arguments.
Maybe this suggests that it is time to bite the bullet and let CLOS
methods discriminate on non-required args, keyword or otherwise. The
last time I heard this discussed, it was more a matter of "we don't want
to think about how to extend the priority rules right now" than "we
can't discriminate on optional args for the following fundamental
reason". Has that changed?
-- Scott
∂08-Jun-87 2001 FAHLMAN@C.CS.CMU.EDU Issue: LOAD-TIME-EVAL (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 20:01:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 23:00:16-EDT
Date: Mon, 8 Jun 1987 23:00 EDT
Message-ID: <FAHLMAN.12309004326.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabsc@HPLABS.HP.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
In-reply-to: Msg of 8 Jun 1987 14:21-EDT from Masinter.pa at Xerox.COM
This looks like a good proposal in general, and it is something I would
like to see adopted. I think that this facility will be used for lots
of things besides CLOS metaclass hackery, and that a less arcane
justification would look better. I seem to recall people asking for
this long before CommonLoops or CLOS appered on the scene.
I'll see if I can come up with some straightforward and self-contained
example that needs this facility. The rest of you should do likewise.
If nobody can do better in the next day or two, I think that this
proposal could go out as is -- I don't think anyone will oppose it, even
if it is presented as an arcane hack needed only by CLOS wizards.
-- Scott
∂08-Jun-87 2126 KMP@STONY-BROOK.SCRC.Symbolics.COM LOAD-TIME-EVAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jun 87 21:26:11 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 167692; Mon 8-Jun-87 23:37:14 EDT
Date: Mon, 8 Jun 87 23:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LOAD-TIME-EVAL
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12309004326.BABYL@C.CS.CMU.EDU>
Message-ID: <870608233713.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
In Maclisp, the SQUID (Self-Quoting Internal Datum) feature in the compiler
offered this same advantage. It was very useful in my Fortran->Lisp translator,
which needed to do the conceptual analog of relocation at load time. I had
one big array called FORTRAN$MEMORY and programs didn't know until load time
what their private data area's offset in that array would be.
I've run into other examples, too, but maybe this suffices to convince people
that CLOS is not the only potential consumer.
Anyway, I'm conceptually in favor of having this capability though I've not
had time to read the particular proposal in detail yet.
∂09-Jun-87 1732 Masinter.pa@Xerox.COM procedural, errors.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 17:32:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 17:32:08 PDT
Date: 9 Jun 87 17:31 PDT
From: Masinter.pa@Xerox.COM
Subject: procedural, errors.
To: FAHLMAN@C.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-173208-1834@Xerox>
I spoke with Kent on the telephone yesterday. Briefly:
Kent will present ignore-errors. He can chose whether he wants to report
it out of the cleanup committee, the error committee, or both, but it
will be go out "under separate cover" so that it is at least apparent
that the error committee approves it.
It turns out that I didn't in fact make any unannounced edits to any
proposals. The wording that upset Kent was the inclusion of the phrase
"including NIL" in KEYWORD-ARGUMENT-NAME-PACKAGE, but the wording was
there (exactly) in the version that got voted on. However, when I fixed
up the line breaks, Kent's source compare didn't work.
So perhaps there weren't any gratuitous and unrecorded changes, although
I admit there were a flurry of hurried ones. In any case, your concerns
have been noted, and I will redouble efforts to avoid any in the future.
I would like to start pipelining proposals out to X3J13, starting with
the ones that have had no discussion for quite a while. The messages to
X3J13 will be careful to say whether the committee voted on the exact
version or some previous one; if there's any doubt, I'll double check
with this mailing list first.
I expect that mail to X3J13 may generate some discussion, questions,
etc. We may want to be prepared to make slight revisions.
∂09-Jun-87 1822 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:21:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:21:23 PDT
Date: 9 Jun 87 18:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@sail.stanford.edu
Message-ID: <870609-182123-1906@Xerox>
Will Clinger mentioned to me at the last X3J13 one important reason for
the stronger interpretation which I hadn't thought of. The issue is
garbage collection of unused functions. The idea is to gc all functions
in the system which aren't called, at the point of building an
application. However, when funcall and friends can automatically coerce
symbols, then any funcall potentially becomes a reference to any
symbol-named function in the environment (without some really hairy and
impossible flow analysis.) If there is no automatic coercion, and there
aren't any explicit symbol-functions, then you can be guaranteed that if
you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
referenced and its definition can be GC'd.
∂09-Jun-87 1835 KMP@STONY-BROOK.SCRC.Symbolics.COM procedural, errors.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:35:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168880; Tue 9-Jun-87 21:34:53 EDT
Date: Tue, 9 Jun 87 21:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: procedural, errors.
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870609-173208-1834@Xerox>
Message-ID: <870609213452.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Larry's message accurately sums up the situation, I think.
I gather that some people worried I might be hopelessly irritated at
Larry, so I should say that I'm not. I was just concerned about a bad
situation which might recur and felt I should say something to keep
things in check. Had it not been so late, perhaps I'd have edited my
comments better.
Larry seems committed to making the documents accurately reflect whether
in fact we've seen or voted on or agreed upon a particular draft, and
that's what's important to this situation.
∂09-Jun-87 1838 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:36:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:36:09 PDT
Date: Tue, 9 Jun 87 18:36:04 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
In-reply-to: <870609-182123-1906@Xerox>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-183609-1934@Xerox>
Date: 9 Jun 87 18:21 PDT
From: Masinter.pa
If there is no automatic coercion, and there
aren't any explicit symbol-functions, then you can be guaranteed that
if
you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
referenced and its definition can be GC'd.
One can always use manual coercion, via EVAL, so you'll also have to
outlaw any calls to thatt function in the application. It starts
seeming like this isn't such a compelling argument.
Pavel
∂09-Jun-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: LOAD-TIME-EVAL (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 20:14:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168944; Tue 9-Jun-87 23:14:13 EDT
Date: Tue, 9 Jun 87 23:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
In-Reply-To: <870608-112516-4180@Xerox>
Message-ID: <870609231403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 8 Jun 87 11:21 PDT
From: Masinter.pa@Xerox.COM
Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL)
I'm generally in favor of something like this proposal, but there are
several problems with the details.
LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
but they are rather different. #, must appear inside a quoted constant,
at least in any compiler implementation I am familiar with, whereas
load-time-eval is a form and must not appear inside a quoted constant.
This is not a fundamental problem, it's just confusing.
The remark "Load time evaluation at the top level is possible using
(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
special form actually does is to inhibit evaluation when loading a file
into the interpreter; it does not cause something to be evaluated at a
different time. I think the real lesson to be learned from this little
slip is that "load time evaluation" is a poor way of describing the
feature we are trying to get at here; the feature we really want is
load-time construction of constants.
It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
subform and what is done with the result. I believe the intention is
that `(foo (load-time-eval (bar))) is roughly like
`(foo (quote ,(bar))), which explains what is done with the result.
I'm not happy with the way I just explained it, but can't think of a
better way. Can the subform be evaluated more than once in interpreted
code?
There are also four typographical errors in the example, or else I am
even more confused by the way it was explained than I thought.
(defmacro call-method (spec &rest args)
`(apply
(load-time-eval
(load-time-look-up-method ,spec))
,args)))
should be
(defmacro call-method (spec &rest args)
`(funcall (load-time-eval
(load-time-look-up-method ',spec))
,@args))
It might be worth discussing the obvious other way of doing this, which
would be a function called by a macro, instead of a special form
included in the expansion of a macro. I think this would have a closer
analogy to #,; in fact you just write , in your macro's backquote where
you would have written #, when using the reader macro. The above
example would be written as follows:
(defmacro call-method (spec &rest args &environment env)
`(funcall (quote ,(make-load-time-eval
`(load-time-look-up-method ',spec)
env))
,@args))
This is more verbose than the special-form way, but it may be clearer
what's going on, since there aren't any special forms. The environment
is passed to make-load-time-eval because I don't see how else it is
supposed to know whether the form resulting from the macro expansion is
going to be compiled into a file or evaluated right away. I'm not sure
we really want to adopt the make-load-time-eval approach, but I think
it may be worth discussing.
I also happen not to believe the stated usefulness of this for object
oriented programming, but that's irrelevant except that I might want to
suggest removing that from the proposal. Certainly we all know that this
type of feature is highly useful.
In conclusion, I support the general idea but cannot support the particular
wording of the current version of the proposal. When I started writing
this message, I was going to include a complete revision of the proposal,
but I have run out of energy.
∂09-Jun-87 2029 Moon@STONY-BROOK.SCRC.Symbolics.COM Hole
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 20:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168954; Tue 9-Jun-87 23:28:33 EDT
Date: Tue, 9 Jun 87 23:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Hole
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Dick Gabriel <RPG@SAIL.STANFORD.EDU>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Message-ID: <870609232830.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Jun 1987 16:40 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Maybe this suggests that it is time to bite the bullet and let CLOS
methods discriminate on non-required args, keyword or otherwise. The
last time I heard this discussed, it was more a matter of "we don't want
to think about how to extend the priority rules right now" than "we
can't discriminate on optional args for the following fundamental
reason". Has that changed?
If I remember (I haven't consulted the archives), it wasn't a case of
"we don't want to think about it". I think we came up with nine
different equally plausible extensions to provide for that case, and
couldn't find any compelling reason to choose one over the others. I
think it would be better for the CLOS committee to concentrate on
finishing what we have tackled so far, and avoid piling on even more
ambitions. These things can be added later.
∂09-Jun-87 2113 Moon@STONY-BROOK.SCRC.Symbolics.COM A Hole in Common Lisp
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 21:12:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168977; Wed 10-Jun-87 00:11:34 EDT
Date: Wed, 10 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A Hole in Common Lisp
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Message-ID: <870610001126.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 6 Jun 1987 21:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Even if I wanted to mix positional and named args in a single function,
I don't like your way of doing it -- it seems treacherous to me. If the
value of certain arguments to a function happen to match the named
arguments, things get interpreted in an unintended and very mysterious
way.
Exactly. If an argument can sometimes be a value for a parameter, and
other times be the name of a parameter, it can be very confusing.
Haven't we seen this same suggestion before and rejected it for that
reason? I can't remember whether "we" was the Common Lisp committee a
few years ago or a bunch of hackers sitting around at MIT a few years
before that. Anyway, my preference is to tread very cautiously on this.
I have sometimes thought that if I were designing a lisp-like language
from scratch, I would leave the question of by-postion or by-name
arguments to the caller of a function....
There [would be] two forms of function calling, positional and by-arg-name
either of which can be used on any function. They need to be
syntactically distinguished somehow. I'll use square brackets to group
the name/argument pairs in the latter -- this might be a read macro that
turns into some three-element list with a reserved token in the car.
(function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)
(function-name [nameX argX] [nameY argY] ...)
This is very like the way Ada does it. If we were redesigning Lisp, my
preference would be to do it this way too. However, I'm sure we'd have
people screaming that we were destroying Lisp by introducing new syntax
and by eliminating the ability to understand keyword arguments in terms
of getf and &rest. Maybe instead of fixing Lisp to be more like Ada, I
ought to be thinking of fixing Ada to be more like Lisp.
∂09-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 23:36:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 23:35:24 PDT
Date: 9 Jun 87 23:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 9 Jun 87 23:14 EDT
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870609-233524-2207@Xerox>
David, I agree with most of your sentiments and encourage you to attempt
a revision. The issue currently has two names, neither of which are
particularly appropriate. One is LOAD-TIME-EVAL, and the other is
SHARP-COMMA-SPECIAL-FORM. Jim's message called it LOAD-TIME-EVAL. I
changed the proposal name to SHARP-COMMA-SPECIAL-FORM in the theory that
the *issue* was some programmatic way of getting at what sharp-comma did
(even if it isn't the same).
#, is one of the stickier bits of Common Lisp, since, like compiler-let
and a few others, it opens a distinction between compiled and
interpreted code that is otherwise outside the execution model. For that
reason, this seems like an issue we might have some difficulty with.
- - - - - - - - - - - - - - -
For general interest, I'll pass along the following: Interlisp has
something like this, in constant, deferredconstant and loadtimeconstant.
(constant x) can be implemented by
(defmacro constant (x) `',(eval x)).
E.g., (constant (char-code #\Space)). Some uses were for those places
where the compiler didn't know enough to do constant folding.
Occasionally it was used for things like (constant (get-date-string))
which would return the date the form was compiled, if at all. Of course,
the interpreted behavior is possibly erratic depending on the mechanism
for macro-expansion caching.
(loadtimeconstant x)
This is similar to constant, but the compiler recognized it specially,
and emitted a special coding so that the loader would evaluate x at load
time. Since it requires special processing by the loader to detect
(e.g., a special case in the fasl format) it is a "special form". I'm
not sure how one could implement this using only a function like
make-load-time-eval. (loadtimeconstant (get-date-string)) would return
the date the compiled code was loaded. Interpreted behavior is similar
to constant, i.e., evaluation time is not specified.
(deferredconstant x)
This gets evaluated on first reference. It can be implemented by
self-modifying code, e.g.,
(defmacro deferred-constant (x)
(let ((var (gentemp)))
(proclaim (list 'special var))
`(if (boundp ',var) ,var (setq ,var ,x))))
In Interlisp implementations that didn't provide load-time-constant, it
was permissible to emulate it using deferred-constant.
∂10-Jun-87 1212 Pavel.pa@Xerox.COM Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 12:12:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 12:09:45 PDT
Date: Wed, 10 Jun 87 12:09:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870610-120945-2854@Xerox>
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, June 10, 1987
Problem description: There are times when users would like to print out
numbers with some punctuation between groups of digits. The "commachar"
argument to the ~D, ~B, ~O, ~X, and ~R FORMAT directives was introduced
to fill that need. Unfortunately, the interval at which the commachar
should be printed is always every three digits. This constraint is
annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES): Add a fourth argument to the ~D,
~B, ~X, and ~O FORMAT directives, and a fifth argument to the ~R
directive, to be called the "comma-interval". This value must be an
integer and defaults to 3. When the : modifier is given to any of these
directives, the "commachar" is printed between groups of
"comma-interval" digits.
Test Cases: Under the proposal, the following forms return the indicated
values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale: The current specification of FORMAT gives the user control
over almost all of the facets of printing integers. Only the wired-in
constant for the comma-interval remains, even though there are uses for
varying that number. For example, in many contexts, it would be
convenient to be able to print out numbers in binary with a space
between each group of four bits. FORMAT does not currently allow
specification of the commachar printing interval so users needing this
functionality must write it themselves, duplicating much of the logic in
every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of
#\Newline and a "comma-interval" of, say, 72, very large bignums could
be printed in such a way as to ensure line-breaks at appropriate places.
Current practice: No released implementations currently support this
feature.
Adoption Cost: The change in the implementation of FORMAT is reasonably
minor and, in most cases, highly localized. Usually, the change is as
simple as taking an extra parameter and using it instead of a wired-in
value of 3.
Cost of non-adoption: Users desiring this functionality will have to
write it themselves, duplicating much of the logic involved in printing
integers at all.
Benefits: The last inflexibility in integer printing is eliminated with
a net increase in user-visible functionality.
Conversion Cost: Since the proposal involves the addition of an argument
to certain directives, the change would be entirely upward-compatible.
No user code would need to be converted.
Esthetics: By parameterizing the final piece of wired-in behavior from
integer printing, this small part of the workings of FORMAT would be
perceived as having been cleaned up.
Discussion: Pavel supports this proposal.
∂10-Jun-87 1357 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Issue: FORMAT-COMMA-INTERVAL
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 13:57:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 183720; Wed 10-Jun-87 16:39:46 EDT
Date: Wed, 10 Jun 87 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
In-Reply-To: <870610-120945-2854@Xerox>
Message-ID: <870610163929.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This proposal sounds good to me.
∂10-Jun-87 1650 FAHLMAN@C.CS.CMU.EDU Issue: FORMAT-COMMA-INTERVAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 16:49:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 10 Jun 87 19:49:05-EDT
Date: Wed, 10 Jun 1987 19:49 EDT
Message-ID: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Msg of 10 Jun 1987 15:09-EDT from Pavel.pa at Xerox.COM
Looks good to me too.
One could quibble about the repeated claim that this is "the last"
inflexibility wired into number printing. I think this is an
overstatement, but not worth a revision, since it is not an important
part of the justification.
-- Scott
∂10-Jun-87 1906 Pavel.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 19:06:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 18:03:54 PDT
Date: Wed, 10 Jun 87 18:03:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870610-180354-1245@Xerox>
Date: Wed, 10 Jun 87 19:49 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
One could quibble about the repeated claim that this is "the last"
inflexibility wired into number printing. I think this is an
overstatement, but not worth a revision, since it is not an important
part of the justification.
Yeah, I felt a little funny about putting it in there, but I guess my
theatric side got the better of me. I agree that it's not really worth
a revision.
Pavel
∂10-Jun-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:27:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169942; Wed 10-Jun-87 22:40:50 EDT
Date: Wed, 10 Jun 87 22:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308703889.BABYL@C.CS.CMU.EDU>
Message-ID: <870610224048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 7 Jun 1987 19:29 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The manual is pretty vague in this area, but my reading of
ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
resulting array is never displaced, even if it had been originally.
That's what we implemented in Spice Lisp, and that's the interpretation
that seems to be consistent with the rest of this proposal (e.g. the rule
that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
than the old index).
Scott, I think you're right. Also I think the second paragraph on p.298
can only be interpreted as saying that if you don't specify :DISPLACED-TO,
it doesn't retain the old displacement.
So I support the earlier version of the proposal, with the added
clarification that if no :DISPLACED-TO argument is supplied in a call to
ADJUST-ARRAY, the resulting array is not displaced, even if the original
array had been displaced. That is clear, simple, and sufficient in my
view.
Agreed.
∂10-Jun-87 2129 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:29:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169946; Wed 10-Jun-87 22:54:29 EDT
Date: Wed, 10 Jun 87 22:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870610225426.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 06 Jun 87 1630 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
I regard this issue as a put-up-or-shut-up affair. I prefer
the formulation that states that APPLY and FUNCALL take functions,
and you have to coerce symbols and lambda-expressions to be functions
before you can APPLY or FUNCALL them to more lenient formulations.
If we do not go with this formulation, then I would say an
important design criterion of the cleanup is:
[updated version of the following quote from a later message substituted
for the original]
``Changes that introduce or retain a multiplicity of rules where a single
rule will do are preferable to changes that cause old programs to stop
working.''
Perhaps I should just keep my mouth shut, but I think that quite a
plausible case can be made that requiring an explicit coercion before
calling APPLY or FUNCALL would be introducing an extra rule and would be
more confusing to new users than permitting the coercion. I don't think
there is one "right" position on this issue, I think it is a matter of
taste and style. I don't think incompatibility with existing programs
is the primary point of resistance on this issue.
I'd really prefer that this matter of taste not hold up agreement on the
important FUNCTION-TYPE proposal. Can we separate out the coercion of
symbols and lambda expressions by function calling into a separate issue?
Dick, I don't know what you meant by "put-up-or-shut-up"; would treating
this as two separate issues be somehow unacceptable to you?
∂10-Jun-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:30:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169947; Wed 10-Jun-87 22:59:21 EDT
Date: Wed, 10 Jun 87 22:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870605-232848-2962@Xerox>
Message-ID: <870610225918.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The adoption cost sentence about some implementations (Symbolics)
already using an optional argument to GET-SETF-METHOD for
something else seems to have disappeared in the latest revision.
I don't care a whole lot, but I don't think we want to cover up
any known adoption costs in proposals.
∂10-Jun-87 2131 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:31:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169951; Wed 10-Jun-87 23:09:08 EDT
Date: Wed, 10 Jun 87 23:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12307710848.BABYL@C.CS.CMU.EDU>
Message-ID: <870610230906.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 4 Jun 1987 00:34 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I support this proposal and have no problem with releasing it as-is,
except for the form in which Moon's comments are included at the end.
As it stands, this is one of those proposals that seems to say, "Let's
do A, but then again we might want to do B."
Unless Moon wants to push the alternative he raises, we should either
drop this comment or say something like the following:
"Moon pointed out that the Symbolics system currently does ..., and that
this is an equally viable alternative. However, the committee has
decided to stick with the proposal as described above."
If Moon strongly favors the alternative he describes, I could support
that as well. I just think we need to pick one or the other.
I don't strongly favor it. I'm sure it was a case of our implementors doing
the best they could to slash their way through the ambiguities of the Common
Lisp book. The way Larry dealt with this in version 3 of the proposal is
fine with me. Note, however, that I cannot support version 3 of the proposal
because of the bug that was introduced in that version (discussed in
separate mail).
∂10-Jun-87 2325 RPG Put Up or Shut Up
To: cl-cleanup@SAIL.STANFORD.EDU
I think a user has to put a multiplicity of rules in his mind when he
reads that FUNCALL calls the function..., when it really invokes the
function or coerces a symbol or a list with a LAMBDA CAR (though that
might fail) to a function and calls that. But a user has fewer rules in
mind when he knows that FUNCALL invokes the function and that there is a
standard way to coerce (COERCE).
What I mean by ``put up or shut up'' is very innocent: This is an issue in
which we either choose to make a true cleanup for aesthetic and political
reasons or we choose not to. If we choose the former, I feel we have
ammunition to use to gain a compromise with EuLisp and Scheme - this would
be fine with me. If we choose the latter, I feel we have to keep Common
Lisp away from being a Lisp (unmodified name) standard, and we must make
sure that ISO Lisp is really ISO EuLisp or some such - this would be fine
with me. Y'all get to put up or shut up, and I get to observe the outcome
and begin to act accordingly, assuming someone wishes me to act at all.
From my own standpoint, I prefer the cleaner formulation, but I am
perfectly happy with the one currently stated in the FUNCTION-TYPE
writeup; if either makes it to the floor of X3J13, I will vote for it.
I am happy to treat the important, undisputed part of the FUNCTION-TYPE
proposal as separate from the only-aesthetic, disputed part of the proposal.
-rpg-
∂11-Jun-87 0958 kempf%hplabsc@hplabs.HP.COM Re: Issue: LOAD-TIME-EVAL (Version 1)
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 09:57:17 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 11 Jun 87 09:57:00 pdt
Received: by hplabsc ; Thu, 11 Jun 87 09:55:53 pdt
Date: Thu, 11 Jun 87 09:55:53 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8706111655.AA00196@hplabsc>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: LOAD-TIME-EVAL (Version 1)
Cc: kempf%hplabsc@hplabs.HP.COM
Well, let's see if I can speak to Dave's concerns about the
proposal.
>LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
>but they are rather different. #, must appear inside a quoted constant,
>at least in any compiler implementation I am familiar with, whereas
>load-time-eval is a form and must not appear inside a quoted constant.
>This is not a fundamental problem, it's just confusing.
The specification for the semantics of #, is found on pg. 356 of CLtL:
#,FOO is read as the object resulting from the evaluation
of the LISP object represented by FOO, which may be the
printed representation of any LISP object. The
evaluation is done during the READ process, unless the
compiler is doing the reading, in which case it is
arranged that FOO will be evauated when the file
of compiled code is loaded. The #, syntax performs
*load-time evaluation* (italics mine) of FOO. By
contrast, #. (see above) performs a read-time
evaluation. In a sense, #, is like specifying
(EVAL LOAD) to EVAL-WHEN, whereas #. is more like
specifying (EVAL COMPILE). It makes no difference
when loading interpreted code; when code is to be
compiled, however, #. specifies compile-time
evaluation and #, specifies load time evaluation.
Since this description says nothing about having #, be inside quoted
code for the compiler, I guess I don't quite understand the confusion,
or, perhaps, am confused myself about how this fits with the model of #,.
I would agree, however, with the statement that LOAD-TIME-EVAL and
#, are different in that LOAD-TIME-EVAL is a form.
>The remark "Load time evaluation at the top level is possible using
>(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
>special form actually does is to inhibit evaluation when loading a file
>into the interpreter; it does not cause something to be evaluated at a
>different time. I think the real lesson to be learned from this little
>slip is that "load time evaluation" is a poor way of describing the
>feature we are trying to get at here; the feature we really want is
>load-time construction of constants.
I agree that a better description of the feature may be load-time
construction of constants; however, in phrasing the proposal, I
was trying to be consistent with CLtL's description of (EVAL-WHEN (LOAD) ...)
specifically (CLtL, pg. 69):
LOAD specifies that the compiler should arrange to evaluate
the forms in the body when the compiled file containing the
EVAL-WHEN form is loaded.
The rest of this section describes Common Lisp's processing model,
into which I was trying to fit this addition.
>It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
>subform and what is done with the result. I believe the intention is
>that `(foo (load-time-eval (bar))) is roughly like
>`(foo (quote ,(bar))), which explains what is done with the result.
>I'm not happy with the way I just explained it, but can't think of a
>better way. Can the subform be evaluated more than once in interpreted
>code?
The subform should be evaluated once and only once (i.e. never
not evaluated and never evaluated more than once) in interpreted
code.
>It might be worth discussing the obvious other way of doing this, which
>would be a function called by a macro, instead of a special form
>included in the expansion of a macro. I think this would have a closer
>analogy to #,; in fact you just write , in your macro's backquote where
>you would have written #, when using the reader macro. The above
>example would be written as follows:
>
> (defmacro call-method (spec &rest args &environment env)
> `(funcall (quote ,(make-load-time-eval
> `(load-time-look-up-method ',spec)
> env))
> ,@args))
>
>This is more verbose than the special-form way, but it may be clearer
>what's going on, since there aren't any special forms. The environment
>is passed to make-load-time-eval because I don't see how else it is
>supposed to know whether the form resulting from the macro expansion is
>going to be compiled into a file or evaluated right away. I'm not sure
>we really want to adopt the make-load-time-eval approach, but I think
>it may be worth discussing.
This would also be acceptable, though, as Dave noted, MAKE-LOAD-TIME-EVAL
would require some way of determining whether the form resulting from
the macro expansion will be compiled or evaluated right away. Since
environments are underspecified in CLtL, this information might not
be obtainable from the environment (though it probably would from special
variables or flags associated with the compiler, in an implementation
dependent way).
>I also happen not to believe the stated usefulness of this for object
>oriented programming, but that's irrelevant except that I might want to
>suggest removing that from the proposal. Certainly we all know that this
>type of feature is highly useful.
The usefulness comes primarily in constructing optimizations removing
method lookup. There are a number of areas where this might be handy,
including direct invocation of less specific methods, declaration of
identifer names and generic function names so particular methods
rather than their generic functions are invoked, etc. To an extent,
these can be viewed as implementation and machine specific (conventional
architecture implementations would probably benefit more), or, more
precisely, implementation and machine optional. However, as pointed
out, the type of feature which the proposal was trying to get at
could be more generally useful.
>In conclusion, I support the general idea but cannot support the particular
>wording of the current version of the proposal. When I started writing
>this message, I was going to include a complete revision of the proposal,
>but I have run out of energy.
If general feeling seems to indicate, I can reword the proposal along
the lines of MAKE-LOAD-TIME-EVAL, or clean up the existing proposal.
One additional problem with the existing proposal is the need and
desire to avoid introducing additional special forms into Common Lisp.
Any other comments?
jak
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 12:47:34 PDT
Date: 11 Jun 87 12:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 10 Jun 87 23:09 EDT
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of
Sun, 7 Jun 87 19:29 EDT
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870611-124734-1571@Xerox>
I intend to revise and recirculate this issue before mailing to X3J13
(unless someone else volunteers to do the revision first.)
Does anyone object to specifying that ADJUST-ARRAY, if no :DISPLACED-TO
argument is given, will always result in a non-displaced array, even if
the array was displaced before?
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:44:03 PDT
Date: 11 Jun 87 13:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Pavel.pa's message of Wed, 10 Jun 87 18:03:40 PDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-134403-1660@Xerox>
If there are no objections, I propose releasing FORMAT-COMMA-INTERVAL to
X3J13, changing "the last" to "one of the last". I'll hold off on this
one until Monday.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:01:24 PDT
Date: 11 Jun 87 15:00 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-150124-1787@Xerox>
Since the "including NIL" was inflammatory, and the proposal reads
nicely and unambiguously without it, I removed it from the Proposal. I
moved the "the cleanup committee generally supports" to the beginning of
the discussion rather than the end, to make sure that it is clear that
it refers to the proposal rather than some sentence of the discussion. I
changed "The cleanup committee considered, but rejected, a proposal to
exclude NIL ..." to say "but did not adopt".
I intend to mail this to x3j13 on Monday unless I hear objections.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:44:56 PDT
Date: 11 Jun 87 14:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
2 May 87 14:43 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-144456-1759@Xerox>
I am having difficulty releasing IF-BODY, because of its length and
form. I think it is an embarassment and will cause an uproar if
presented in its present form.
I wouldn't mind a proposal that contained all of the words and
discussions of this one, but in the discussion section. I think most of
the other issues can be summarized succinctly and fairly.
While I hate to do this (and possibly it is a mistake) I am going to
attempt to do the surgery to put Version 5 in a releasable form
(although we are all sick of it). You'll probably hate me for it, but
I'd rather not foist it in its current form on the community.
∂11-Jun-87 1726 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Jun 87 17:26:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 170782; Thu 11-Jun-87 20:17:58 EDT
Date: Thu, 11 Jun 87 20:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870611-124734-1571@Xerox>
Message-ID: <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Unless there's a compelling reason not to, I think it's important to always
make ``keyword NIL'' mean the same as not having supplied the keyword. There's
only a few cases where we violate this and if anything we should be working
on reducing the number of cases.
I think :DISPLACED-TO NIL should copy into a new area and give back a
non-displaced array, so I agree that this should be the behavior in the
case of omitting :DISPLACED-TO.
Since we're guaranteeing that levels of array displacement will never
be optimized out, it would seem to me reasonable to provide functions
to ask an array whether it is displaced, and if so to what at what index.
Perhaps:
ARRAY-DISPLACED-TO array [Function]
Returns the array to which the argument <array> is displaced, or
NIL if the argument <array> is not displaced.
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Returns the displaced-index-offset of the argument <array>, or
NIL if the argument <array> is not displaced. (If <array> has been
displaced to another array, but no displaced-index-offset was specified,
this function returns 0.)
Example:
(ADJUST-ARRAY THE-ARRAY THE-NEW-DIMENSIONS
:DISPLACED-TO (ARRAY-DISPLACED-TO THE-ARRAY)
:DISPLACED-INDEX-OFFSET (ARRAY-DISPLACED-INDEX-OFFSET THE-ARRAY))
These operations might also be of use to certain people wanting to write
highly optimized array manipulation code that wanted to accept arguments
which might be displaced arrays, but which didn't want to have to incur the
displacement overhead internally.
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:05:20 PDT
Date: 11 Jun 87 16:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>
Please pay special attention to the issues marked *. I believe these
are the ones where last-minute wording changes might have invalidated
consensus. I hope I was adequately cautious in my mailing to X3J13.
I am going to be on vacation starting next Wednesday until right before
the X3J13 meeting.
David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.
We have a request from Skona Brittain (an X3J13 member from
Microcomputer Systems Consultants in Santa Barbara) to join the cleanup
committee. Unfortunately, she does not have mail access. While it seems
unlikely that anyone not on the net could usefully participate, I am
reluctant to turn down enthusiastic volunteers.
!
In this file: EB = Benson, GLS = Guy Steele,
PC = Pavel Curtis, KMP = Kent Pitman, SEF = Scott Fahlman,
LMM= Larry Masinter
[name/initials] position => person had position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.
Withdraw = "Place on hold pending resolution of comments already
received."
! released
* nearly ready for release
! Proposal format (Version 11)
Released 11-Jun-87 13:07:17
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Comments & edits after ballot.
Not ready for release
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
comments from Moon, JonL, SEF against current form
[EB, PC, SEF] Withdraw
Not ready for release
! AREF-1D (Version 5)
(Add a new function for accessing arrays with row-major-index)
[all] Version 2 with name => ROW-MAJOR-AREF
Version 5 released 11-Jun-87 13:07:50
* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
(Extend ASSOC-IF, etc. to allow :KEY)
[EB, GLS, KMP] Release as is
[LMM] ASSOC-IF has CAR for KEY?
Reply?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
Version 3 released.
Version 6 released 11-Jun-87 13:15:29
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87 13:30:32
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87 13:30:22
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
[EB, GK] DO-SYMBOLS:ALLOWED
[PC, Moon, LMM] something like :ADD-KEYWORD
not ready for release
ENVIRONMENT-ARGUMENTS (Version 1)
Separated into other proposals.
Withdrawn.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Released 11-Jun-87 13:36:10
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
Version 3 released.
Version 4 released 11-Jun-87 13:44:27.
* FORMAT-COMMA-INTERVAL (Version 1/10 June)
Ready for release?
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
! FORMAT-OP-C (Version 5/ 11-Jun-87 14:00:19)
(What does ~C do?)
Release to X3J13
FUNCTION-TYPE (Version 4/ 29-May-87)
(Change definition of FUNCTIONP, function type ...)
[EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
addressed
[KMP] break in two, so I could
support the half I like and only grump about the parts I don't
want stronger warning
[SEF] 2-option, 3-option version
Not ready for release
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
[EB, GLS, PC, Moon, SEF] Release as is
[GK] Ballot says comments follow, but no comments?
[KMP] NIL as null lexical environment
Released 11-Jun-87 14:18
* IF-BODY (Version 5, 29 Apr 87)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
While EB, PC, Moon voted to wait for a version that KMP and SEF
agreed was fair, SEF said 5 was fair enough.
LMM will reformat
IGNORE-ERRORS (Version 4, 29-May-87)
[EB, LMM, PC, Moon] Wait for error proposal
[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...")
KMP will release as report from cleanup + error committee
! IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
Version 3 Released
Version 5 released 11-Jun-87 14:48:33
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments
Ready for release?
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
Moon may rewrite? (Please)
Not ready for release
MACRO-FUNCTION-ENVIRONMENT
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
! PATHNAME-STREAM (Version 2)
[EB, GK, PC, Moon, SEF] Release as is
Released 11-Jun-87 15:03:54
PATHNAME-SYMBOL (Version 2)
[GLS, PC, Moon, KMP, SEF] Release as is
[eb] against, want minority view (needs formatting)
Moon " cover every argument that is called pathname,
filename, file, or new-name
and leave the rest of the ambiguities for another proposal?"
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal
Not ready for release
! PRINC-CHARACTER (Version 3)
Released 11-Jun-87 15:35:59
PROCLAIM-LEXICAL (Version 1)
In discussion
Some progress
Need volunteer to merge comments into new version
Not ready for release
PROMPT-FOR (Version 1)
Agreed to be controversial
[EB, PC, Moon, SEF] Withdraw
Not ready for release
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
[PC, SEF] (PUSH FIRST SECOND)
Not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
("A hole in Common Lisp: RPG/....")
Not yet submitted
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
[EB] Unchanged [PC, KMP, SEF] Undecided
Not ready for release
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
[EB] Release as is
[pc, KMP] no, remove bits & font
want fuller character proposal
not ready for release
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
[RPG against, GLS for, SEF reluctant, etc.]
not ready for release
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal
not ready for release
SPECIAL-FORM-SHADOW
Is it OK to shadow a special form with FLET, LABELS?
Not yet submitted
(From ENVIRONMENT-ARGUMENTS)
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
Notes from Moon
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:45:14 PDT
Date: 11 Jun 87 15:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-154514-183@Xerox>
At an earlier meeting, there was some discussion over registering the
list of "public" features and "system" packages so that different
implementations would not step over each other in their use of them.
(For example, Xerox uses XCL:, as did one of the X-in-Common-Lisp
modules. User code that explicitly referenced XCL:DRAW would have to be
edited explicitly.)
This seems actually to get more at the heart of the matter than the
current proposals for #+- and the like.
Perhaps we could discuss this at our meeting?
∂11-Jun-87 1846 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:46:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:49:30 PDT
Date: 11 Jun 87 16:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 10 Jun 87
23:25 PDT
To: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-164930-206@Xerox>
I missed this message, sorry.
I think we have agreement to release the form of FUNCTION-TYPE which
allows implicit coercion in FUNCALL and APPLY. Can someone produce a
new version of the proposal? It would be good if we could release it by
X3J13.
Richard, I think that your position about the EULisp community is
unnecessarily extreme, but I will address that in a separate message.
∂11-Jun-87 2045 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D (Version 2)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 20:45:45 PDT
Received: by navajo.stanford.edu; Thu, 11 Jun 87 20:42:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA26428; Thu, 11 Jun 87 18:26:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA14620; Thu, 11 Jun 87 18:28:39 PDT
Date: Thu, 11 Jun 87 18:28:39 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706120128.AA14620@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 2 Jun 87 01:22 EDT <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)
Your note of 2-Jun says that I "supported" the ammended version. I don't
remember voting any issue, or even particularly arguing for one point of
view or the other. The relevant comment from me was merely that GLS's
"clarifications" of 6-Dec-86 used ROW-MAJOR-AREF for the same thing your
proposal was using AREF-1D for, and that Lucid had already implemented it
under the 6-Dec-86 name. Wouldn't it be better to mention the 6-Dec-86
"Clarifications" rather than deduce my (non-voting) support?
-- JonL --
∂11-Jun-87 2121 FAHLMAN@C.CS.CMU.EDU Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 21:21:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 00:21:02-EDT
Date: Fri, 12 Jun 1987 00:20 EDT
Message-ID: <FAHLMAN.12309805464.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Status
In-reply-to: Msg of 11 Jun 1987 19:05-EDT from Masinter.pa at Xerox.COM
With regard to the request from Skona Brittain, I think we should see
what can be done to get her arpanet access via dialup to some nearby
machine. However, as long as she is not able to receive and send
netmail, I don't think she should be considered part of this committee.
It means that someone would have to take the responsibility for sending
this stuff out in hardcopy, and it means that we would have to wait
around for arbitrarily long periods waiting for her input and votes. I
don't think we can even invite her to the face-to-face meetings -- she
would be missing too much context.
She is of course welcome to submit issues and to participate in the
final votes -- all X3J13 members get to do that.
-- Scott
∂12-Jun-87 0939 Masinter.pa@Xerox.COM Re: Hm
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 09:39:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 09:38:06 PDT
Date: 12 Jun 87 09:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Hm
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 12 Jun 87
01:32 PDT
To: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
to: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870612-093806-1562@Xerox>
JonL: regarding your support of ROW-MAJOR-AREF, I interpreted your
wording "Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this
addition seemed very natural and `called for'. So Lucid Common Lisp has
had it available since shortly thereafter. " to be support.
If you don't intend to support this proposal and want to raise some
objection to it, I can send out an amended version of the proposal with
your objections contained in it.
Richard (and others):
In the status report, the initials [rpg], [jonl] etc. were only my
summary of the ballots, e.g., if you answered the mail with
***BALLOT***. They don't reflect any additional comments or positions
in separate mail.
∂12-Jun-87 1040 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 10:40:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 10:24:45 PDT
Date: 12 Jun 87 10:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-102445-1632@Xerox>
My idea with FUNCTION-TYPE is to bring out a proposal which includes the
automatic coercion of symbols to functions, puts forward the removal of
the coercion in the discussion section (as possibly a new proposal) and
for this to be a discussion item at X3J13. It will be hard for it to be
a discussion item if it doesn't go out in the mail. The discussion
section of the proposal should say something like "The cleanup committee
generally supports this proposal, as far as it goes. Some members of the
committee feel strongly that it does not go far enough. We believe this
is an issue which deserves wider discussion in the community, since it
affects the position of X3J13 and Common Lisp with respect to the EuLisp
community."
Is that OK?
I'm trying hard to keep the administration of this uncolored by my own
opinion on the issues.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here's my opinion on the issue:
I promised a message on the issue of compatibility and our negotiating
position with EuLisp and ISO. I am finding it very difficult to compose.
The X3J13 statement clearly includes as one of the options we are able
to take is to propose a layered implementation strategy, i.e., that
there are simpler subsets of Common Lisp, full Common Lisp, and
supersets of full Common Lisp.
I believe that our current goal is to properly remove the ambiguities in
full Common Lisp and, where warrented, consider minor enhancements.
When dealing with subsets and supersets, I think that we also have
additional goals, that the layers properly nest (programs in a subset
will run in a superset), that it be possible (either by static analysis
or runtime) to tell whether a program in a superset would run in a
subset, etc.
I believe the proper position with regard to EuLisp and ISO's desire for
a simpler language as a standard is for it to be a subset.
In the case of the FUNCTION-TYPE issue, it is critical that the FUNCTION
type be well specified in full Common Lisp, if it is a first-class type
in any subset. Otherwise, programs which depended on a clean dynamicly
accurate FUNCTIONP would not run in (arbitrary) full Common Lisp
implementations.
However, there is no need to remove the automatic coercion of symbols
and LAMBDA expressions in FUNCALL, APPLY and friends. It is certainly
possible to have a subset which does not include coercions which the
full language provides.
With regard to simplicity and coercions, the automatic coercion of
symbols and lambda expressions to their designated functions is not a
lot more complex than the coercion of (symbols?) and strings to
pathnames, or possibly even integers to complex floats.
∂12-Jun-87 1906 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 19:06:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 21:36:21-EDT
Date: Fri, 12 Jun 1987 20:12 EDT
Message-ID: <FAHLMAN.12310022293.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE
In-reply-to: Msg of 12 Jun 1987 13:24-EDT from Masinter.pa at Xerox.COM
I think that if we agree to settle on the coercing version of this
proposal now and to discuss the more radical version later, we almost
guarantee that the radical version will not be seriously considered in
our lifetimes. We will have established a new status quo that is
tolerable, more or less, and it will be very hard to move away from that
to something better (if we decide it is indeed better).
I think that it would be best to present both plans to X3J13 and to
discuss the merits of each at the meeting, and then if the coercing
version is the best we can do, so be it; we shouldn't kid ourselves that
a more radical cleanup of this issue will be considered later.
-- Scott
∂12-Jun-87 1943 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-DISPLACEMENT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 19:43:11 PDT
Received: by navajo.stanford.edu; Fri, 12 Jun 87 19:40:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01678; Fri, 12 Jun 87 17:25:25 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01339; Fri, 12 Jun 87 17:27:22 PDT
Date: Fri, 12 Jun 87 17:27:22 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130027.AA01339@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 11 Jun 87 20:17 EDT <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
You suggest adding two new functions to Common Lisp:
ARRAY-DISPLACED-TO array [function]
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
DISPLACED-ARRAY-P array [Function]
"which takes an array and returns NIL and 0 if it is not displaced or the
array displaced to and the displaced-index-offset if it is displaced."
Wouldn't it be much better to adopt the "Clarifications" approaches, where
appropriate, since some, if not several, implementations have already
implemented them?
-- JonL --
∂12-Jun-87 2255 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 22:55:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:54:31 PDT
Date: 12 Jun 87 22:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
12 Jun 87 20:12 EDT
To: Fahlman@C.CS.CMU.EDU
cc: Masinter.pa@Xerox.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-225431-2538@Xerox>
Puerhaps I wasn't clear. I think that the discussion of the coercion of
FUNCALL and APPLY is a central, and very important to discuss, at this
X3J13. However, I think it is separable from the issue of the FUNCTION
type, and the changes to FUNCTIONP and TYPEP of FUNCTION. And, it
seems valuable to separate them, since, while they are both compatible
changes, there is not necessarily any correlation between whether one
supports one and the other, since their justifications and motivations
are not identical.
My proposal is to separate them. One issue is FUNCTION-TYPE. What is
the other issue called? I had tentatively named it FUNCTION-COERCION. A
proposal just arrived from Will Clinger, with selective linking as the
central theme (I alluded to this in an earlier message.) I will mail
this out in a separate message (EVAL-DEFEATS-LINKER). If your sentiment
is that we should not release one issue without the other, I agree, it
seems poor form and might let one get lost in the face of the other. If
you would like to keep them together in the same proposal, please
explain.
Thanks,
Larry
∂12-Jun-87 2256 Masinter.pa@Xerox.COM Issue: EVAL-DEFEATS-LINKER
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 22:55:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:55:21 PDT
Date: 12 Jun 87 22:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-DEFEATS-LINKER
To: cl-cleanup@Sail.stanford.edu
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870612-225521-2539@Xerox>
Date: 12 Jun 87 15:36:10 PDT (Fri)
Issue: EVAL-DEFEATS-LINKER
References: Functions (p32); FUNCTIONP (p76); APPLY (pp107-108);
FUNCALL (p108); #. (pp355-356); #, (p356)
Category: CHANGE
Edit history: 12-Jun-87, Version 1 by Clinger
Problem description:
It appears to be impossible to write a selective linker for Common Lisp
that is both reliable and effective. The reason is that most programs
must call APPLY, FUNCALL, or READ, which potentially call SYMBOL-FUNCTION
or EVAL, which must be regarded as potential references to any standard
or user-defined Common Lisp procedure. At a minimum, therefore, the
entire Common Lisp library gets linked into the deliverable application.
Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):
Change the definition of the function type to exclude symbols and lists.
Change the definition of FUNCTIONP to be false of symbols and lists.
Change the definitions of APPLY and FUNCALL so it is an error to pass
them a symbol or a list as their first argument.
Functions such as MAPCAR that are defined by reference to the concept of
function or by reference to APPLY and FUNCALL would be affected by these
changes as well, but it would not be necessary to change their
written specification.
Remove the #. and #, dispatching macro characters from the standard reader
syntax. Require the interpreter, compiler, and interactive loader to use
a reader syntax that has been extended by adding the #. and #, dispatching
macro characters.
Test Case:
The executable file for the following program is comparable in size to
a complete Common Lisp system.
(DEFUN MAIN ()
(PRINT (EVAL (READ))))
A selective linker should, however, be able to link the following program
into a relatively small executable file.
(DEFUN MAIN ()
(PRINT (APPLY (FOO) (READ))))
(DEFUN FOO ()
(LET ((BIAS (RANDOM 1000)))
#'(LAMBDA (&REST ARGS) (+ BIAS (APPLY #'+ ARGS)))))
Currently selective linkers have difficulty with the preceding program
because they must also make programs like the following work, where FOO
"computes" an arbitrary function. Under the proposal, the only ways
to compute an arbitrary function would be through explicit use of EVAL
or SYMBOL-FUNCTION et cetera.
(DEFUN MAIN ()
(PRINT (APPLY (FOO) (READ))))
(DEFUN FOO () (READ))
Rationale:
Selective linking is essential for most industrial applications. Symbols
and lambda expressions are regarded as functions for historical reasons
only. The description of the #, dispatching macro character on p356
suggests that both #. and #, are intended for use in code, not in data
to be read by an application program.
Current practice:
Hardly any implementations of Common Lisp attempt to remove unnecessary
code from a deliverable application. Those that do appear to ignore the
problems posed by the third test case, and are therefore unreliable.
That is, they are incorrect because they behave as though this proposal
has been adopted when it has not.
Adoption Cost:
Implementations do not actually have to change APPLY and FUNCALL, since
they would not have to signal an error when passed a symbol or list.
Implementations that rely on #. and #, in non-code data would suffer
a conversion cost, but it seems unlikely that any implementations do this.
Cost of non-adoption:
Selective linking will continue to be unavailable or unreliable.
Benefits:
The availability of reliable selective linkers will make Common Lisp suitable
for a much braoder range of applications.
Conversion Cost:
Programs for which reliable selective linking is unimportant (that is,
essentially all current Common Lisp programs) can be converted by
redefining APPLY and FUNCALL and by defining the #. and #, dispatching
character macros. This will be referred to below as the trivial conversion.
Programs for which reliable selective linking is important, if any exist,
are presumably written in a style that needs no conversion.
To convert an existing program into a style that can be linked selectively,
it is necessary to examine all calls to APPLY, FUNCALL, MAPCAR, and other
functions that take functions as arguments. Where the argument expression
is of the form (FUNCTION f), no conversion is necessary. Where the first
argument is of the form (QUOTE f), it should be changed to (FUNCTION f).
Where the first argument is of neither of these two forms, human intervention
will be necessary. It seems likely that most calls will have first arguments
of the form (FUNCTION f) or (QUOTE f), so this conversion can be automated
substantially but not completely.
As with all conversions, arguments to EVAL must be analyzed specially.
Since uses of EVAL generally defeat selective linking, however, it is
clear that programs that make extensive use of EVAL were not intended
to be passed through a selective linker. Hence the trivial conversion
should suffice for such programs.
If the program reads data from files, then it may be necessary to scan the
files for occurrences of #. and #,. If any occurrences are found, they
will have to be removed. It seems clear, however, that no program intended
for selective linking will rely on #. and #, in data files.
Esthetics:
This proposal simplifies Common Lisp by removing weird special cases that
contribute to the language's reputation for inefficiency.
Discussion:
This is a good example of the practical importance of aesthetics in language
design. The difficulties implementors face in writing a selective linker
for Common Lisp are inherent in the current language definition. It is
better to fix the language than to postulate sufficiently clever linkers.
While this proposal will make it possible to construct selective linkers,
it will not make it trivial. In many implementations, for example, the
data structure for each symbol contains among other things a pointer to
the symbol's home package, a value cell, and a function cell. In such an
implementation each symbol may represent a potential reference to the value
cell of any symbol accessible from its home package. Implementations that
care about selective linking may have to break such links.
Scheme proves that it is possible to design a Lisp that can be linked
selectively. Reliable selective linkers have been written for T and for
MacScheme, and possibly for other implementations as well.
∂13-Jun-87 0042 edsel!bhopal!jonl@navajo.stanford.edu Hm
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Jun 87 00:42:20 PDT
Received: by navajo.stanford.edu; Sat, 13 Jun 87 00:39:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA02160; Fri, 12 Jun 87 23:04:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01882; Fri, 12 Jun 87 23:06:05 PDT
Date: Fri, 12 Jun 87 23:06:05 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130606.AA01882@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!RPG%SAIL.STANFORD.EDU@navajo.stanford.edu,
navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 12 Jun 87 09:37 PDT <870612-093806-1562@Xerox>
Subject: Hm
Goodness no, by no means do I want to raise an objection to the AREF-1D
proposal. I only wanted to make it perfectly clear that my interest
was not so much "support" or "criticism" of the overall proposal, but
a reminder that the 6-Dec-85 "Clarifications" had already addressed the
functional issue, and had already picked the name ROW-MAJOR-AREF. I guess
I wasn't so "perfectly clear".
Eric Benson has already cast the Lucid vote in support of the proposal.
-- JonL --
∂14-Jun-87 1136 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jun 87 11:36:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 172424; Sun 14-Jun-87 14:28:35 EDT
Date: Sun, 14 Jun 87 14:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8706130027.AA01339@bhopal.edsel.uucp>
Message-ID: <870614142825.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 12 Jun 87 17:27:22 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
You suggest adding two new functions to Common Lisp:
ARRAY-DISPLACED-TO array [function]
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
DISPLACED-ARRAY-P array [Function]
"which takes an array and returns NIL and 0 if it is not displaced or the
array displaced to and the displaced-index-offset if it is displaced."
If you code up the same example as I sent in my last message using
the function DISPLACED-ARRAY-P, you'll see that it's a lot more clumsy.
To me, the presence of these two functions makes the need for
DISPLACED-ARRAY-P seem unnecessary while at the same time making
code that actually needs this information look a lot better.
Wouldn't it be much better to adopt the "Clarifications" approaches, where
appropriate, since some, if not several, implementations have already
implemented them?
I certainly admit that I didn't look in the clarifications before
sending that message. I should have.
Ultimately, however, the clarifications are just one person's opinion (albeit
the opinion of one who is very highly respected). They still have to get voted
on just as do anyone else's suggestions. And while I admit that we shouldn't
try to gratuitously perturb things that people have already implemented where
it is reasonable to avoid doing so, I don't think we are obliged to
unconditionally support an implementation's decision to introduce these
primitives `prematurely'.
As it happens, I don't like functions with predicate-sounding names being
used for non-predicate values, so I'm not sure that I would have really
wanted to go with this clarification if I had a choice. eg, whenever I
use DIGIT-CHAR-P for value, I do
(DEFUN DIGIT-WEIGHT (&REST ARGS) (APPLY #'DIGIT-CHAR-P ARGS))
and use DIGIT-WEIGHT instead. I find that expressions like
(+ (* VALUE RADIX) (DIGIT-CHAR-P CHAR))
look really awful in practice and can't bring myself to write them.
∂15-Jun-87 1919 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:19:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 13:23:44 PDT
Date: 15 Jun 87 13:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 22 Apr 87 15:14 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870615-132344-158@Xerox>
I've been unable to find any other implementation (outside of symbolics)
that has ASSOC-IF-KEY. I looked at Spice, Xerox and VaxLisp. I'm uneasy
saying that the others are "split down the middle" if they aren't.
I tried to generate a test case. Can you think of something more
illuminating than
(ASSOC-IF #'ZEROP '(("ABC" . 3) ("E" . 4) ("" . 7)) :KEY #'LENGTH)
=> ("" . 7)
∂15-Jun-87 1920 Masinter.pa@Xerox.COM READ TODAY: Cover letter for mailing to X3J13
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:20:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:44:09 PDT
Date: 15 Jun 87 14:29 PDT
From: Masinter.pa@Xerox.COM
Subject: READ TODAY: Cover letter for mailing to X3J13
To: cl-cleanup@sail.stanford.edu
Message-ID: <870615-144409-103@Xerox>
I want to mail this tomorrow, as I must get the hardcopy version out,
and I am leaving town. Please reply asap. Also, while there have been a
couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
will attend?
Scott is working on FUNCTION-TYPE, and Kent on IF-BODY. It seems
important to get those versions in the hands of X3J13 in advance of the
meeting, so that there can be some meaningful discussion. I have
tentatively put new version numbers down with today's date.
If the versions can be distributed to cl-cleanup today, there's a chance
of mailing them with the other hardcopy versions tomorrow (and I will
change the cover letter.) Otherwise, they will have to be distributed at
the meeting.
!
Dear X3J13 members:
Enclosed are several proposals from the cleanup committee for your
examination. The committee has been "meeting" via electronic mail. For
each proposal, there has been an average of 10-15 messages.
In most cases, the cleanup committee has explicitly endorsed the
proposal -- i.e., we all think it is a good idea. In some cases, while
the committee has generally agreed that the proposal is a good idea,
there hasn't been sufficient time to obtain agreement about the exact
form of the proposal; in those cases, while an earlier version was
circulated among the cleanup committee. In most of these proposals, some
earlier version was circulated to the committee and explicitly voted on.
In a few cases (identified in the proposal) there has been a great deal
of disagreement, but that we generally thought that we should bring the
matter to the attention of the larger group, for discussion and
guidance.
For your information, I have listed below all of the issues currently
under consideration, with an extremely brief description of the issue.
If anyone is interested in further details, or in joining the cleanup
committee, please let us know (CL-CLEANUP@Sail.stanford.EDU). Those
issues which are included in this mailing (and were mailed electronicly)
are marked with a !. Those marked with * were nearly ready for release,
but a final version is not available. We hope to have final versions of
these at the meeting.
!
! Proposal format (Version 11)
Format for proposals to the cleanup committee.
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs no :displaced-to.
Not ready for release
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release
! AREF-1D (Version 5/11 Jun 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Almost ready for release
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 3 released.
Version 6 released 11-Jun-87.
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87 13:30:32
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87 13:30:22
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available
not ready for release
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
Not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Released 11-Jun-87
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 3 released.
Version 4 (re-)released 11-Jun-87 13:44:27.
* FORMAT-COMMA-INTERVAL (Version 1/10 June)
(Allow another argument to ~D etc to paramerize digits between commas)
Almost ready for release
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
! FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Released 11-Jun-87
* FUNCTION-TYPE (Version 4/ 15-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Not quite ready for release
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 released 11-Jun-87
* IF-BODY (Version 7, 15-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Not quite ready for release
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee
! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 3 Released
Version 5 released 11-Jun-87
! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
( &KEY arguments not in keyword package?)
Version 6 released 15-Jun-87
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
! PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Released 11-Jun-87 15:03:54
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release
! PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Released 11-Jun-87 15:35:59
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
[PC, SEF] (PUSH FIRST SECOND)
Not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, no proposal submitted
REMF-DESTURCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
not ready for release
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
not ready for release
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
not ready for release
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS?)
In discussion, no proposal submitted yet
TAILP-NIL
(Operation of TAILP given NIL)
Not yet submitted.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release
∂15-Jun-87 1938 FAHLMAN@C.CS.CMU.EDU READ TODAY: Cover letter for mailing to X3J13
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:38:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 15 Jun 87 22:37:15-EDT
Date: Mon, 15 Jun 1987 22:37 EDT
Message-ID: <FAHLMAN.12310835145.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: Msg of 15 Jun 1987 17:29-EDT from Masinter.pa at Xerox.COM
The second sentence in this paragraph isn't a sentence, and I can't
figure out what it's trying to say. Something got garbled.
In most cases, the cleanup committee has explicitly endorsed the
proposal -- i.e., we all think it is a good idea. In some cases, while
the committee has generally agreed that the proposal is a good idea,
there hasn't been sufficient time to obtain agreement about the exact
form of the proposal; in those cases, while an earlier version was
circulated among the cleanup committee. In most of these proposals, some
earlier version was circulated to the committee and explicitly voted on.
In a few cases (identified in the proposal) there has been a great deal
of disagreement, but that we generally thought that we should bring the
matter to the attention of the larger group, for discussion and
guidance.
I'm not sure I'd mention the "not yet submitted" issues at all in this
list. If the idea is to solicit proposals on these issues from outside
the cleanup committee, that's OK, but in that case we need to describe
the problem better, and I would argue that this should be done in a
separate communication. I don't feel passionately about this, but I do
think it's a bit confusing.
Otherwise, this looks OK to me.
-- Scott
∂15-Jun-87 2042 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: EVAL-DEFEATS-LINKER
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87 20:42:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173727; Mon 15-Jun-87 23:41:49 EDT
Date: Mon, 15 Jun 87 23:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-DEFEATS-LINKER
To: Masinter.pa@Xerox.COM, willc%tekchips.tek.com@RELAY.CS.NET
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870612-225521-2539@Xerox>
Message-ID: <870615234142.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 12 Jun 87 22:55 PDT
From: Masinter.pa@Xerox.COM
Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):
I don't think this is a good choice of name, because only the third paragraph
of the proposal has anything to do with EVAL. EVAL-DEFEATS-LINKER:CLOSED-SYSTEM
would be a better name, and EVAL-DEFEATS-LINKER:REMOVE-FUNCTION-COERCION would
be even better if the readtable part is dropped as I suggest below. This is
nit-picking, of course.
Change the definition of the function type to exclude symbols and lists.
Change the definition of FUNCTIONP to be false of symbols and lists.
The above two lines are redundant with the FUNCTION-TYPE proposal. I guess
that means that this proposal has FUNCTION-TYPE as a prerecquisite.
Change the definitions of APPLY and FUNCALL so it is an error to pass
them a symbol or a list as their first argument.
Functions such as MAPCAR that are defined by reference to the concept of
function or by reference to APPLY and FUNCALL would be affected by these
changes as well, but it would not be necessary to change their
written specification.
This is the first cogent argument I have seen for why APPLY and FUNCALL should
not coerce names of functions to functions. I'm glad to see the discussion
getting real.
One way to address the conflict between compatibility with existing
programs and the proposed automated subsetting of Common Lisp by observing
what features are manifestly used by a given program, would be to note the
use of the phrase "is an error". This allows all existing implementations
to agree on an extension to Common Lisp to support coercion of function
names to functions, i.e. to agree to continue to do what they do now, while
not requiring future implementations to support that. Programs that exploit
that feature would no longer be portable in law, but would remain portable
in practice, which seems like a desirable state of affairs.
These existing implementations could also agree on a switch that disables
the extension, to facilitate portability to implementations that lack the
extension. I have to caution, however, that implementing such switches as
dynamic variables generally does not work in implementations where the
operating system is written in Lisp; we have some distasteful experience
with that in the areas of case-sensitivity in string comparison and
NIL-sensitivity in CAR and CDR. Implementing the switch in a lexical way,
for instance by providing a package containing alternate versions of
FUNCALL, APPLY, and every CL function that calls FUNCALL or APPLY, would
avoid this problem. There may be other techniques that are more
appropriate than switches. Unfortunately reliance on coercion from
function names to functions is not, in general, detectable at compile time.
If it was detectable at compile time, this whole linker issue would not
have arisen.
Remove the #. and #, dispatching macro characters from the standard reader
syntax. Require the interpreter, compiler, and interactive loader to use
a reader syntax that has been extended by adding the #. and #, dispatching
macro characters.
I see no reason to include this third part in the proposal. Common Lisp already
provides ways to make customized readtables, and applications that want to run
in stripped-down Lisps can use those mechanisms to make readtables that don't
contain #. and #, and can inform their linker that they are using those mechanisms.
The proposal should mention the existence of the #. loophole, of course.
Isn't #S a bit of a loophole, also, although not quite as bad?
I have thought of one additional loophole; perhaps the best way to describe it
is with an example.
(defvar *funcall-loophole*)
(deftype funcall ()
`(satisfies ,*funcall-loophole*))
(defun funcall-the-old-way (symbol argument)
(let ((*funcall-loophole* symbol))
(typep argument 'funcall)))
(funcall-the-old-way '1+ 5) => 6
Perhaps a linker can be written to detect the presence of DEFTYPEs complex
enough that they could be this loophole. I could have written this without
using any special variables, and without using DEFTYPE; I just put those in
to make it look more complicated and thus harder to detect at compile time.
The key point here is that the SATISFIES type-specifier is defined to call
SYMBOL-FUNCTION. I don't think we want to change that.
∂15-Jun-87 2140 Moon@STONY-BROOK.SCRC.Symbolics.COM READ TODAY: Cover letter for mailing to X3J13
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87 21:40:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173769; Tue 16-Jun-87 00:30:59 EDT
Date: Tue, 16 Jun 87 00:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: READ TODAY: Cover letter for mailing to X3J13
To: Masinter.pa@Xerox.COM, Masinter.pa%Xerox.COM@MC.LCS.MIT.EDU
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870615-144409-103@Xerox>
Message-ID: <870616003052.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Jun 87 14:29 PDT
From: Masinter.pa@Xerox.COM
I want to mail this tomorrow, as I must get the hardcopy version out,
and I am leaving town. Please reply asap.
This didn't make it from Xerox to Stanford until 5 hours after you sent it,
so expect delayed replies. The evidence of a network problem somewhere is
why I'm sending this in a way that should get you three copies.
Also, while there have been a
couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
will attend?
I haven't heard of this meeting before. Gee, did I arrange it in my sleep?
As far as I know now I can attend, although something might come up.
I have no comments on the letter to X3J13 members, other than seconding
Fahlman's comment on fractured English in one place.
∂16-Jun-87 0159 Masinter.pa@Xerox.COM Re: READ TODAY: Cover letter for mailing to X3J13
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 01:59:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 01:50:08 PDT
Date: 16 Jun 87 01:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 16 Jun 87 00:30 EDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <870616-015008-1540@Xerox>
Thanks for the note on the mail delay. They were tinkering with the
mail-server today (moved it to another net), unfortunately, and mail got
temporarily delayed while it was down.
I will fix up the brain-damaged paragraph.
As for the meeting, maybe David was asleep after all?
.....
From: masinter.pa
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>
...
MEETING:
I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.)
What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?
Other agenda items?
...
Date: Tue, 2 Jun 87 00:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ballots, meeting, etc.
To: masinter.pa
In-Reply-To: <870531-205005-2070@Xerox>
Message-ID: <870602002903.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
...
We can get a small (12-person) conference room at Symbolics if a room
elsewhere doesn't materialize. I would need to sign up for it a few
days in advance to be sure to have it all day Monday. We're at the
opposite end of the MIT campus from the Marriot hotel where apparently
people are staying, but it's within walking distance unless the weather
is outrageously hot.
Date: 11 Jun 87 16:05 PDT
From: Masinter.pa
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>
...
David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.
...
∂16-Jun-87 0608 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 06:08:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 09:07:25-EDT
Date: Tue, 16 Jun 1987 09:07 EDT
Message-ID: <FAHLMAN.12310949843.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 5)
I have written up a version of this proposal that presents the two
options we have discussed the most as alternatives. The idea is that we
can perhaps debug this proposal before the Boston meeting, and then have
something concrete and written-down to discuss with the whole X3J13
group. Perhaps that discussion will lead to some consensus or at least
to a clear view of which way the majority of X3J13 wants to go. A mail
ballot after the meeting could make things official in that case. Of
course, it is also possible that people will decide to postpone the
difficult issues and just vote on the type cleanup, without deciding how
the resulting types may be used.
By writing up these two options, I do not mean to preclude others.
However, the only other proposal that has appeared is the one from KMP
that we require a symbol's function cell to accept symbols and lambda
expressions as well as true functions and to return unchanged whatever
was put there. Kent has indicated some ambivalence about whether he
wants to press forward with this option, which has not received any
support from others on the committee. If he does want to press this,
he should write up this option himself, since I don't really understand
the fine points of his position.
Since I won't be there, I have included my own vote at the end. I have
also included what I believe to be RPG's position, since he has made his
views known repeatedly. I'm not sure exactly where the rest of you
stand at present.
Many small things had to be changed to make this a two-option proposal,
so it is probably best for you to consider this a new proposal and read
it over carefully. The major substantive change is in point 3 (now in
two distinct versions). There are also some changes in "cost of
conversion" -- see if you believe my argument that mechanical conversion
of old code to adhere to the strict form of the proposal is possible
and that the result is not significantly less efficient than building
the coercions into FUNCALL and APPLY. Also, look over the discussion
section and see if I have seriously misrepresented anyone's views.
-- Scott
---------------------------------------------------------------------------
Status: To be discussed at X3J13 meeting (?). This is a
tough but important issue that involves some fundamental
trade-offs, so discussion by the whole X3J13 committee
is called for.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs
the status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Two alternative proposals are presented here:
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION. Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
Proposal FUNCTION-TYPE:COERCING-REDEFINITION
This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.
RATIONALE:
Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.
The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.
Adoption Cost:
For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified
to deal with functions that are not lists (but from which the list form
can be easily reconstructed if necessary).
If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so. Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
BENEFITS:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
CONVERSION COST:
The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do. One impact on
user-level code would be a change in the operation of certain type
predicates. Such cases should be relatively easy to find and fix.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted. However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions. CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.
Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.
AESTHETICS:
Making the concept of a function well-defined will probably be perceived
as a simplification.
The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals. The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.
DISCUSSION:
This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions. Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.
Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION. The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.
Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal. They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.
Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.
White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.
Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems. He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.
Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.
Clinger has suggested that the strict form is preferable because it makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.
∂16-Jun-87 1338 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jun 87 13:38:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 174496; Tue 16-Jun-87 16:35:22 EDT
Date: Tue, 16 Jun 87 16:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
To: Masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870615-132344-158@Xerox>
Message-ID: <870616163500.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 15 Jun 87 13:23 PDT
From: Masinter.pa@Xerox.COM
I've been unable to find any other implementation (outside of symbolics)
that has ASSOC-IF-KEY. I looked at Spice, Xerox and VaxLisp. I'm uneasy
saying that the others are "split down the middle" if they aren't.
I think I didn't have access to other lisps in order to try it on the day
I sent that message. If none of the other lisps you know do it, then I'm
happy to say under current practice that only we are known to have implemented
the extension.
I tried to generate a test case. Can you think of something more
illuminating than
(ASSOC-IF #'ZEROP '(("ABC" . 3) ("E" . 4) ("" . 7)) :KEY #'LENGTH)
=> ("" . 7)
Well, I don't like to think of a non-accessor as the :KEY, though this
is technically fine. We should probably give some advice about this in
the sample cleanup template; my feeling is that the test case just has
to illustrate the feature, not motivate it. Under this criterion, the
case above is fine.
The problem with a simple test case is that the need for this only comes up
in real program situations where objects with structured parts appear in
alists. In that case, you might have something like:
(DEFSTRUCT FOO X)
(ASSOC-IF #'IDENTITY '((#S(FOO :X NIL) 3 4) (#S(FOO :X T) 7)) :KEY #'FOO-X)
or
(ASSOC-IF #'PROBE-FILE '((#S(FOO :X "FOO.LSP") 3 4) (#S(FOO :X "BAR.LSP") 7))
:KEY #'FOO-X)
for that matter. In a real program, the #S(...) forms would presumably not be
constant -- they'd be pushed on by programs calling constructors -- and this
latter example doesn't return a constant value across implementations, but it
hopefully gives you a sense of what you can do. Another case might be:
(DEFVAR *KNOWN-PACKAGES* (MAPCAR #'FIND-PACKAGE '("LISP" "KEYWORD")))
(DEFUN KNOWN-PACKAGE-P (PACKAGE) (MEMBER PACKAGE *KNOWN-PACKAGES*))
(ASSOC-IF #'KNOWN-PACKAGE-P '((FROB . FUNCTION) (IF . SPECIAL-FORM))
:KEY #'SYMBOL-PACKAGE)
=> (IF . SPECIAL-FORM)
A situation that seems most familiar to me takes more work to set up:
(DEFUN FULL-DIRECTORY-LIST (WILD-PATHNAME)
"Returns (wild-path (path1 :WRITE-DATE date1 :AUTHOR author1) ...)."
(LET* ((PATHS (DIRECTORY WILD-PATHNAME))
(DATES (MAPCAR #'FILE-WRITE-DATE PATHS))
(AUTHORS (MAPCAR #'FILE-WRITE-DATE PATHS)))
(CONS FILES
(MAPCAR #'(LAMBDA (PATH DATE AUTHOR)
(LIST PATH :WRITE-DATE DATE :AUTHOR AUTHOR))
PATHS DATES AUTHORS))))
In this case, you could imagine a variety of ASSOC-type operations that you
might want to do on the pathname in the car of each list in the cdr of the
result. In general, it's true that you can always write:
(ASSOC-IF #'(LAMBDA (P) (MEMBER (PATHNAME-TYPE P) '("LSP" "L" "LISP")
:TEST #'STRING-EQUAL))
(CDR DIRECTORY-LISTING))
but somehow I find it more aesthetic to see:
(ASSOC-IF #'(LAMBDA (TYPE) (MEMBER TYPE '("LSP" "LISP" "L")))
(CDR DIRECTORY-LISTING)
:KEY #'PATHNAME-TYPE)
so that the key extraction and the predication are separate. This increases
the likelihood that the function in the predicate position will already exist
with some known name. For example, going back to your original example,
there is no function which does (ZEROP (LENGTH x)) but there are functions
ZEROP and LENGTH which work together well in the place where :KEY is provided.
Feel free to extract any part of this message that moves you and add it to
the proposal if you feel it's warranted. Doubtless this text is too long
and rambly to be included as a whole.
∂16-Jun-87 1945 edsel!bhopal!jonl@navajo.stanford.edu READ TODAY: Cover letter for mailing to X3J13
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 19:45:14 PDT
Received: by navajo.stanford.edu; Tue, 16 Jun 87 19:42:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA10855; Tue, 16 Jun 87 18:34:50 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01141; Tue, 16 Jun 87 18:37:02 PDT
Date: Tue, 16 Jun 87 18:37:02 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706170137.AA01141@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 15 Jun 87 14:29 PDT <870615-144409-103@Xerox>
Subject: READ TODAY: Cover letter for mailing to X3J13
I believe that Dick will attend the Monday meeting at Symbolics on Jun 29.
He is out of town now and won't be back til sometile Thursday.
-- JonL --
∂16-Jun-87 2040 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 20:40:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 23:39:12-EDT
Date: Tue, 16 Jun 1987 23:39 EDT
Message-ID: <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: EVAL-DEFEATS-LINKER
In-reply-to: Msg of 13 Jun 1987 01:55-EDT from Masinter.pa at Xerox.COM
This proposal seems very odd to me.
It is certainly desirable for a Common Lisp implementation to have some
way to create a core image for application delivery that contains only
as much code as that application needs, and not all the rest of Common
Lisp and the associated development environment. I have argued that
this approach to application delivery is much better than trying to
create some small delivery-oriented subset of Common Lisp: it is better
to keep those functions that you actually use and jettison the rest than
to try to guess in advance what subset would be appropriate for a whole
class of appliction.
A normal garbage collection will keep alive all of the functions that
are actually needed by a given application program, either directly or
indirectly. Unfortunately, it will also keep alive every other function
that is globally named by a symbol, even if that symbol is not mentioned
in the application code. Such functions are still "accessible" if there
is a read/eval present, since the user could ask for them by name, so
the garbage collector is not allowed to eliminate them.
We could get rid of these named functions if, by examining all the
application code, we could prove any of the following:
1. The symbol is not mentioned in the application and there is no way to
smuggle it into the system at runtime via calls to read, intern, etc.
2. The function is not called anywhere, and the symbol, though it may be
present, is not converted into a function anywhere. Clinger's proposal
is to make this proof easier by eliminating a large class of implict
symbol-to-function conversions.
3. The function, though it may be present, is not called and is nowhere
passed to EVAL, APPLY, or FUNCALL.
That's one approach to eliminating the unneeded parts of Common Lisp. A
different approach is is to simply ask the user to declare that the
application does not contain a full Common Lisp interpreter, if that is
his intent. For example, an implementation might provide a facility
called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
functions and everything that they call (transitively), but that flushes
all other functions that are normally found in a Common Lisp.
If such an application happens to have an EVAL lurking within, and if
the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
Y-OR-N-P is simply undefined. Sorry, but this is a desk calculator, not
a full Common Lisp interpreter.
It seems to me that the latter approach is by far the more interesting
and useful one. It also seems to me that this is an environment issue
and not something that this committee needs to worry about. I see no
significant portability issue here. In the compressed system, EVAL
doesn't mean quite what it did before, but nobody is claiming that this
desk calculator is a legal common lisp. Exactly what COMPRESS retains
will depend on the internal details of each implementation, so there is
no point in trying to standardize this.
-- Scott
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:18:19 PDT
Date: 16 Jun 87 15:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
16 Jun 87 09:07 EDT
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870616-151819-260@Xerox>
Thanks, Scott.
Given that some important members of the community don't have regular
mail access, I think it would disenfranchise them to *not* mail this
issue out. I think your rewrite looks very good. Since I'm mailing the
other issues this afternoon, I am going to release your version, intact.
I will precede it with an introduction.
∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
barmar
∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.
CONVERSION COST:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.
∂17-Jun-87 1941 edsel!bhopal!jonl@navajo.stanford.edu Issue: EVAL-DEFEATS-LINKER
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 19:41:40 PDT
Received: by navajo.stanford.edu; Wed, 17 Jun 87 19:39:01 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA00489; Wed, 17 Jun 87 19:21:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03068; Wed, 17 Jun 87 19:23:56 PDT
Date: Wed, 17 Jun 87 19:23:56 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706180223.AA03068@bhopal.edsel.uucp>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu,
navajo!willc%tekchips.tek.com%RELAY.CS.NET@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Tue, 16 Jun 1987 23:39 EDT <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Subject: Issue: EVAL-DEFEATS-LINKER
I think I'll have to agree generally with your analysis of this problem.
At Lucid, we have spent a good deal of time working on a tool similar to
what you called COMPRESS-FOR-DELIVERY, and the results are not uniformly
heartwarming. Primarly, the mass of data involved in keeping track of all
the constraints is a quagmire [that perhaps needs an expert system for
solution?]; so it is not at all as simple a task as it seems at first.
Re: We could get rid of these named functions if, by examining all the
application code, we could prove any of the following: ... [and]
Clinger's proposal is to make this proof easier by eliminating a
large class of implict symbol-to-function conversions.
I'm just as skeptical as you are about the usefulness of making a
controversial change in CL semantics just in order to remove one small
aspect of the many hurdles in front of the impossible proof. Many of
the alleged dangers of the symbol-to-function mapping are in fact
compile-time "harmless"; e.g. (mapc 'list l1 l2) should cause no one
any more concern than (mapc #'list l1 l2), so why restrict it? Also I
like to write code like
(dolist (fn '(a b c d e f))
;; Install the "boot level" versions of these basic functions
(setf (symbol-function fn)
(symbol-function (append-symbols 'boot- fn))))
Rather than throw out the baby with the bathwater, I'd much rather have a
declaration that said something like "This instance of symbol-function is
restricted to the set of symbols {a b c d e f boot-a boot-b ... boot-f}".
Somehow, if the "proof" were ever made to be successful, I fear that the
resultant language would be so much more like Pascal, and so little like
the classic Lisps that the AI world grew up on, that X3J13 might just as
well admit defeat and join the FortranADAPascalCModula crowd.
-- JonL --
∂18-Jun-87 1126 RPG FUNCTION-TYPE (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
I also believe that we should release this proposal to a larger
community. Scott's rendering of it seems good; his representation of
my position is accurate.
-rpg-
∂18-Jun-87 1132 RPG FUNCTION-TYPE (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
BARMAR's correct, we forgot to include an extension to COERCE on pages
51-52 to coerce symbols and certain lists to functions. I recall
formulating an intention to mail such a proposal, but it seems I forgot.
-rpg-
∂19-Jun-87 1429 @RELAY.CS.NET:willc@tekchips.tek.com Re: Issue: EVAL-DEFEATS-LINKER
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Jun 87 14:29:06 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac22243; 19 Jun 87 16:05 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aq09203; 19 Jun 87 15:56 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA22564; Fri, 19 Jun 87 12:11:47 PDT
Received: by tekchips.TEK.COM (5.51/6.22)
id AA01863; Fri, 19 Jun 87 12:14:18 PDT
Message-Id: <8706191914.AA01863@tekchips.TEK.COM>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: Fahlman@C.CS.CMU.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: Issue: EVAL-DEFEATS-LINKER
In-Reply-To: Your message of Tue, 16 Jun 1987 23:39 EDT.
<FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Date: 19 Jun 87 12:14:16 PDT (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
This is my response to a message from Scott Fahlman.
> This proposal seems very odd to me.
Cultural differences account for this:
I think ordinary programs (which don't call EVAL or any of its subspecies)
should be linked selectively with no special effort. This is what people
do every day with other programming languages, including Scheme. I
couldn't care less about programs that explicitly call EVAL or its
subspecies, because Real Programmers don't call EVAL.
Scott wants programs that call EVAL or its subspecies, which he and
his culture consider to be normal programs, to be linked selectively.
This requires the user to name all the functions that might be involved
in a call to EVAL. He couldn't care less about programs that don't call
EVAL or its subspecies, because Real Programmers call EVAL.
> A normal garbage collection will keep alive all of the functions that
> are actually needed by a given application program, either directly or
> indirectly. Unfortunately, it will also keep alive every other function
> that is globally named by a symbol, even if that symbol is not mentioned
> in the application code. Such functions are still "accessible" if there
> is a read/eval present, since the user could ask for them by name, so
> the garbage collector is not allowed to eliminate them.
The second sentence is correct only if EVAL or one of its subspecies is called
explicitly, the language is poorly designed, or the implementation is not
structured for selective linking. I don't think programs that call EVAL
are worth worrying about, and I'm trying to patch the language design so
future implementatations can be designed for selective linking. Note that
READ without EVAL would cause no problems for selective linking in a well-
designed implementation if it weren't for the language problems I have
identified.
> That's one approach to eliminating the unneeded parts of Common Lisp. A
> different approach is is to simply ask the user to declare that the
> application does not contain a full Common Lisp interpreter, if that is
> his intent. For example, an implementation might provide a facility
> called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
> functions and everything that they call (transitively), but that flushes
> all other functions that are normally found in a Common Lisp.
>
> If such an application happens to have an EVAL lurking within, and if
> the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
> Y-OR-N-P is simply undefined. Sorry, but this is a desk calculator, not
> a full Common Lisp interpreter.
>
> It seems to me that the latter approach is by far the more interesting
> and useful one. It also seems to me that this is an environment issue
> and not something that this committee needs to worry about. I see no
> significant portability issue here. In the compressed system, EVAL
> doesn't mean quite what it did before, but nobody is claiming that this
> desk calculator is a legal common lisp. Exactly what COMPRESS retains
> will depend on the internal details of each implementation, so there is
> no point in trying to standardize this.
>
> -- Scott
My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language. His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.
Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies. If we change FUNCALL and
APPLY as I propose, and go further to fix everything else that depends on
EVAL and its subspecies, then I would be very sympathetic to the idea of
dropping EVAL, SYMBOL-VALUE, and SYMBOL-FUNCTION and their ilk from the
supported language. I doubt that Scott really wants to go that far.
================================================================
I am sympathetic to David Moon's suggestion that #. and #, could be
left out of the proposal, since programs that want to be linked
selectively can just define #. and #, to be something innocuous.
-- Will
∂19-Jun-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87 17:37:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Jun 87 20:36:06-EDT
Date: Fri, 19 Jun 1987 20:36 EDT
Message-ID: <FAHLMAN.12311861665.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: EVAL-DEFEATS-LINKER
> This proposal seems very odd to me.
Cultural differences account for this:
Yeah, I guess so. I actually don't object to your proposal. I've got
no objection to your kind of "selective linking with no special effort"
if a system wants to supply it. I think that a system geared for
application delivery wants to have the kind of user-specified
compression I described in the previous note, but if some compression
can happen automatically, so much the better. If the price for this is
flushing the coercion in APPLY and FUNCALL, that just gives me another
reason to favor FUNCTION-TYPE:STRICT-REDEFINITION, which I support for
other reasons anyway. Like Moon, I dislike the change to #. and #, ,
but I guess that's not a big issue here.
My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language. His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.
Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies.
Well, not really. It's another matter of culture, I guess, but I think
of this as leaving the semantics of EVAL alone; EVAL still treats a
symbol defined as a function just as before. What changes is the set of
symbols that happen to have functional definitions at runtime. Think of
it as coding in a Common Lisp subset, but you don't choose the subset
until the program is done and you examine what functions you actually used.
I suppose that flushing something like ATANH at compression time could
be viewed as changing the semantics of EVAL, and I suppose you could say
that this is disastrous because EVAL is used to define other things, but
I don't really see this as a useful way to look at the world. If you
take this view, doesn't it also change EVAL (in a disastrous way) when
you define some new function?
-- Scott
∂22-Jun-87 2236 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 22:35:54 PDT
Date: 23 Jun 1987 01:34-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: Masinter.pa@XEROX.COM
Message-ID: <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
In-Reply-To: <870616-155121-101@Xerox>
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.
For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if *debugging-p*
`',fname
`#',fname)))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p* '|#!-reader| #'|#!-reader|))
Then, I can code the following (in most implementations):
(proclaim '(optimze (speed 0) (safety 3)))
(proclaim '(notinline froz))
(eval-when (compile load eval) (defparameter *debugging-p* t))
(defun froz ...)
...(funcall #!froz ...)...
...(mapcar #!froz ...)...
(defparameter *action-seq* `(,#!froz ,#!zorf ,#!(lambda ...) ...))
...
(apply (elt *action-seq* i) ...)
I can at any time trace froz in order to find out what is going on
(besides tracing I may also do some types of profiling). (Cf. trace,
pg 441.) And what is probably even more important, when my
observation of the behavior of froz leads me to redefine froz, every
piece of code or data-structure that references the function name froz
will correctly get the new definition.
As CLtL is currently vague as to when it is permissable to dereference
a function name to its definition (compile-time, load-time, or
apply-time), I have to avoid implementations that do not deference at
apply-time.
Under the strict redefinition proposal, I would have to recompile
every data structure that contained #'froz. In other words, it would
make functional objects impratical to debug.
Under both proposals. function names (i.e., symbols and
lambda-expressions) are (virtually) eliminated as functional objects.
This is great way to "purify" the semantics of the language, but it
puts a big burden on implementors to come up with development environments
that have the ease of debugging that function names provided.
I think I have probably mixed up a few issues here (it is late for
me), but I wanted to put in my warning that flushing function names
that can be passed around as functions has some major consequences on
Lisp style due to debugging/redefinition issues.
-- Nick
∂23-Jun-87 0809 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 08:09:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 23 Jun 87 10:57:54-EDT
Date: Tue, 23 Jun 1987 10:57 EDT
Message-ID: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@G.BBN.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987 01:34-EDT from NGALL at G.BBN.COM
There are lots of ways in which an implementation could provide tracing
facilities for anonymous function objects. For human-interface
purposes, function objects would be identified using some label that is
derived from the original name under which the funciton was defined.
This information could be hidden in some slot of the function object or
(somewhat more portably) associated with it in a hashtable.
I haven't thought this through, but I bet that one could develop a trace
facility like the one you describe, but using anonymous stand-in
functions that print something and then call the original function
(which can be redefined) rather than using a symbol as a wrapper. This
might even be strictly portable, which your hack is not.
If the same debugging functionality can be achieved in a different way,
I don't see the elimination of one dubious hack as a strong argument for
keeping the status quo.
-- Scott
∂23-Jun-87 0948 edsel!kent-state!eb@navajo.stanford.edu Issue: FUNCTION-TYPE (Version 5)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 09:48:42 PDT
Received: by navajo.stanford.edu; Tue, 23 Jun 87 09:45:40 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA12003; Tue, 23 Jun 87 09:15:21 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA08001; Tue, 23 Jun 87 09:16:28 PDT
Date: Tue, 23 Jun 87 09:16:28 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706231616.AA08001@kent-state.edsel.uucp>
To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!NGALL@G.BBN.COM's message of 23 Jun 1987 01:34-EDT <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
Subject: Issue: FUNCTION-TYPE (Version 5)
Date: 23 Jun 1987 01:34-EDT
Sender: navajo!NGALL@G.BBN.COM
From: navajo!NGALL@G.BBN.COM
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.
For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if *debugging-p*
`',fname
`#',fname)))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p* '|#!-reader| #'|#!-reader|))
Here's a version of your debugging environment that adheres to the
strict definition of functions:
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if (consp fname)
`#',fname
(if *debugging-p*
`#'(lambda (&rest x) (apply #',fname x))
`#',fname))))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p*
#'(lambda (&rest x) (apply #'|#!-reader| x))
#'|#!-reader|))
∂23-Jun-87 1145 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87 11:44:55 PDT
Date: 23 Jun 1987 14:43-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]23-Jun-87 14:43:05.NGALL>
In-Reply-To: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>
Date: Tue, 23 Jun 1987 10:57 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
I haven't thought this through, but I bet that one could develop a trace
facility like the one you describe, but using anonymous stand-in
functions that print something and then call the original function
(which can be redefined) rather than using a symbol as a wrapper. This
might even be strictly portable, which your hack is not.
That's the problem. No implementations (except perhaps Symbolics)
seem to have thought through encapsulation issues (of which tracing is
but one example). Thus in many implementations, tracing functions
called from compiled code, even with speed 0 and safety 3 and
notinlines, does not work, or only works in some situtations.
If the same debugging functionality can be achieved in a different way,
I don't see the elimination of one dubious hack as a strong argument for
keeping the status quo.
That's a big IF in my opinion, given that most implementations have so
far only provided the crudest of tracing and breaking facilities
(which all depend on apply-time deferencing of function-names).
It is not entirely clear from your response what you consider to be my
dubious hack. If you mean that depending on implementations to
dereference function-names (i.e., symbols) at apply time (unless
declarations permit otherwise), then I must disagree with you.
Virtually all Lisp interpreters have this behavior, it is the
compilers that cause inconsistent behavior. And since one of Common
Lisp's major goals is to "impose identical semantics" on compiled and
interpreted code, I claim that my examples were perfectly correct CL
programs and compilers that don't enforce proper dereferencing are
broken.
The ability to apply function names (and have them deferenced as late
as possible) may have gotten into Lisp for
dubious reasons, but it has been a very strong reason why Lisp has
succeeded as a flexible, incremental, and rapid development
environment. If we remove this feature without alternative mechanisms
ALREADY IN PLACE, we will make Lisp debugging more primitive than
conventional language debugging.
-- Nick
∂23-Jun-87 1538 RAM@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 15:38:19 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 23 Jun 87 18:37:27-EDT
Date: Tue, 23 Jun 1987 18:37 EDT
Message-ID: <RAM.12312888633.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: NGALL@G.BBN.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987 14:43-EDT from NGALL at G.BBN.COM
Since this message addresses compiler semantics, I thought I'd comment
on it...
Date: Tuesday, 23 June 1987 14:43-EDT
From: NGALL at G.BBN.COM
To: Fahlman at C.CS.CMU.EDU
Re: Issue: FUNCTION-TYPE (Version 5)
[...] It is not entirely clear from your response what you
consider to be my dubious hack. If you mean that depending on
implementations to dereference function-names (i.e., symbols) at
apply time (unless declarations permit otherwise), then I must
disagree with you. Virtually all Lisp interpreters have this
behavior, it is the compilers that cause inconsistent behavior.
And since one of Common Lisp's major goals is to "impose identical
semantics" on compiled and interpreted code, I claim that my
examples were perfectly correct CL programs and compilers that
don't enforce proper dereferencing are broken.
Perhaps unfortunately, it isn't possible to implement anything that
could reasonably be called a "compiler" so that it has exactly the
same semantics as traditional interpreters. The entire purpose of a
compiler is to make use of compile-time information in order to
transform the program into a more efficient and more specific program.
In my compiler cleanup proposal, I argue that Common Lisp shouldn't
talk about the semantics of compiled v.s. interpreted code, instead it
should define "evaluation" in a way that is broad enough to encompass
both compiled and interpreted evaluation strategies. This mostly
amounts to saying "It is an error to write a program that cannot be
compiled.", since there are few things a compiler can do that
interpreters don't.
The ability to apply function names (and have them deferenced as
late as possible) may have gotten into Lisp for dubious reasons,
but it has been a very strong reason why Lisp has succeeded as a
flexible, incremental, and rapid development environment.
This is a valid point, but it doesn't directly translate into marching
orders for Common Lisp standardization. We should attempt to design
Common Lisp so that it doesn't preclude useful environment features,
but we are not obligated to provide them directly in the language.
I agree with you that it should be possible to force compilers to do
full function call, but the issues aren't totally clear. For example,
the functions that are being expanded inline are presumably standard
Common Lisp functions. It is all very well to say "NOTINLINE inhibits
inline expansion", but this capability is of little use unless you can
redefine standard functions. [Which was discussed to death on
common-lisp a while back.]
You must always remember that when Common Lisp says that something "is
an error", implementations are not forbidden to assign meaning to that
usage. If there is a feature that is needed to support an environment
so amazing mind-bogglingly whizzy that you can't live without it, then
everybody will want that kind of environment support, and all
"reasonable" implementations will provide it. This in itself is not a
particularly strong argument for standardizing the *feature that
supports the environment*. It is only when we start talking about
portable environment facilities that we become concerned.
The concept of a "reasonable" implementation is also important.
Common Lisp does not reqire implementations to be reasonable; it only
requires that programs meeting the specification run in all
implementations (subject to resource limitations and other ill-defined
vaguenesses.) It is not a valid argument to say "X must be in Common
Lisp because I refuse to use a system that doesn't support X." You
must demonstrate that X aids significantly in writing interesting
portable programs, rather than simply allowing you to hack in the
manner to which you have become accustomed.
Rob
∂25-Jun-87 2333 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE: not allowing symbols to be used as functions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87 23:33:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182745; Fri 26-Jun-87 01:43:35 EDT
Date: Fri, 26 Jun 87 01:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE: not allowing symbols to be used as functions
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870626014327.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
*MACROEXPAND-HOOK* is another one you overlooked. Its default value
is the symbol FUNCALL, and its value gets funcalled, therefore it
relies on funcalling a symbol and would need to be reworked.
∂26-Jun-87 1104 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Issue: IF-BODY (Version 7)
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87 11:04:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 13:02:58-CDT
Date: Fri, 26 Jun 87 13:02 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP%Sail.stanford.edu@MCC.COM
cc: Masinter.pa%Xerox.COM@MCC.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870626130230.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
If I were to change IF to allow multiple else causes I would like to
change IF to be like Bernie Greenberg's IF in his Multics Emacs
implementation, namely:
(IF test then-clauses :ELSE else-clauses)
This certainly would be incompatible with existing code but would allow
both multiple THEN and ELSE clauses.
-- David D. Loeffler
∂29-Jun-87 2239 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-DOCUMENTATION (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87 22:39:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185077; Tue 30-Jun-87 01:27:05 EDT
Date: Tue, 30 Jun 87 01:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR-DOCUMENTATION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870630012646.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is not explicit about whether the documentation part of
DEFVAR, DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and
DEFCONSTANT special forms is not evaluated. That is, it must be
a literal string, not a form which evaluates to a string.
Rationale:
To ensure portability, implementations must agree on whether or not
this position is evaluated. Specifying that the position is unevaluated
is the conservative thing to suggest.
Current Practice:
Some implementations evaluate this position. Others do not.
Adoption Cost:
The change is presumably trivial in all implementations.
Benefits:
Code portability would be improved.
Conversion Cost:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed.
Aesthetics:
No significant impact.
Discussion:
Pitman thinks this is a good idea.
∂06-Jul-87 1658 Masinter.pa@Xerox.COM AREF-1D (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jul 87 16:57:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUL 87 16:45:33 PDT
Date: 6 Jul 87 16:45 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 6)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870706-164533-1986@Xerox>
This revision clarifies the proposal by giving arguments and some
equivalence relations. I added that row-major-aref was usable with SETF
(which did not appear in the original proposal although it was implied
in one of the examples.)
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when
the elements of array are considered in row-major order. Array may be an
array of any dimensionality. row-major-aref may be used with setf. For
reference, the following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts
..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)
----- End Forwarded Messages -----
∂13-Jul-87 1257 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 12:54:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870713-125407-2098@Xerox>
We are tasked with producing a new version of FUNCTION-TYPE for
consideration at the next X3J13. The new version should reflect the
discussion held so far. My notes and memory are poor. Does anyone else
have any notes?
My notes include that point 6 (the description of COMPILE) should be
removed from this proposal, that there was some sentiment for
considering a proposal where symbols coerced to their symbol-function
but lists did not, consideration of APPLICABLE-P, a proposal where
FUNCTION and FUNCTIONP stayed the same but there was a new type
PROCEDURE and PROCEDUREP, that we be more consistent about justifying
removing COMPILED-FUNCTION-P (i.e., why bother?), that the proposal
mention selective linking.
Some of the discussion centered around the merits of Dynamic Linking and
the Value of Lisp, the behavior of COERCE and the FUNCTION type.
∂13-Jul-87 1321 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply. A SETF method applies only when the global function binding
of the name is lexically visible. All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro
expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂13-Jul-87 1344 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply. A SETF method applies only when the global function binding
of the name is lexically visible. All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro
expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂13-Jul-87 1415 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 14:15:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 14:11:08 PDT
Date: 13 Jul 87 14:05 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Status
Message-ID: <870713-141108-2238@Xerox>
This is my status file.
Please reply with individual messages about each issue.
At the face-to-face meeting before X3J13, we discussed the remaining
issues in Clarifications.txt. I will be sending out separate messages
about each of those under the heading of an issue name I will ascribe,
and will then add those issues to the status file.
I intend to segment this status file into Active, Passed and Tabled
Indefinitely. (I suppose there might be some argument about dividing
things between Active and Tabled, but I urge you to avoid arguing about
it until there's an issue that I've marked Tabled that you want to
continue to discuss.)
!
Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
(Suggestion to add a Related Issues field.)
ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Masinter to revise, clarify :displaced-to ommitted'
same as :displaced-to nil.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
Conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup.
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Not ready for release.
Needs revision of current practice, test case, example. (KMP?)
The summary says Version 2, but I only have version 1 on file.
Does anyone else have a version 2? Or was this wishful thinking?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
Postponed pending error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13/Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release.
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release.
Was discussion at X3J13 conclusive?
Should this issue be abandoned? (cc: clinger, please)
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
In discussion, formal proposal not yet submitted.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Ready for release.
FORMAT-NEGATIVE-PARAMETERS
In discussion, formal proposal not yet submitted.
Notes: is this an editorial policy question rather than
an individual issue?
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions?
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
(Was not released).
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
Deferred to compiler committee?
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
Masinter will extract from environment-arguments
* PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Needs revision to clarify "file" = "opened with open"
(there are some non-file devices which have pathnames)
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
Moon will revise, extend language, clarify
which functions are affected, etc.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
Pitman will revise & resubmit.
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
Rees & Moon will revise & resubmit. Rees says he won't.
David?
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
Tabled indefinitely.
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
Need volunteer to submit.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
Table indefinitely.
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
Pitman will revise & resubmit.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
Forward to Linden for character proposal?
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
Pitman will revise & resubmit.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
Send to macro committee?
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
Masinter will revise & resubmit.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
Gabriel will revise & resubmit.
∂15-Jul-87 1329 Masinter.pa@Xerox.COM Issue: Pathname-subdirectory-list
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jul 87 13:29:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 JUL 87 13:27:05 PDT
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: Pathname-subdirectory-list
To: cl-cleanup@sail.stanford.edu
cc: Ghenis.pasa@Xerox.COM
Message-ID: <870715-132705-3165@Xerox>
This arrived in my mailbox before the X3J13 meeting. While I suspect
there may be some alternative proposals, and perhaps some other
important related issues, this seems like a good way to introduce the
topic.
!
ISSUE: (PATHNAME-SUBDIRECTORY-LIST)
REFERENCES: CLtL pages 409 - 418
CATEGORY: ADDITION
EDIT HISTORY: Version 1 by Ghenis.pasa@Xerox.com, 06/18/87
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
The string form of a pathname can be obtained by using the appropriate
OS-specific separator and end-delimiters.
Require global variables called LISP:*HOST-OS-ALIST* and
LISP:*DEFAULT-OS* to provide the information needed to assemble
namestrings correctly
TEST CASE (desired behavior):
>(defparameter LISP:*HOST-OS-ALIST*
'(("vmsvax" . "vms") ("unixvax" . "unix"))
>(defparameter LISP:*DEFAULT-OS* "msdos")
>(defvar vmspath
(make-pathname :host "vmsvax"
:directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(defvar localpath
(make-pathname :directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(namestring vmspath)
"{vmsvax}[smith.lisp]test.lsp"
>(namestring localpath)
"c:\smith\lisp\test.lsp"
RATIONALE:
Pathnames are an abstraction meant to deal with the common notions in
file systems. Subdirectories exist in most operating systems. Common
Lisp must provide a standard way of dealing with subdirectories for
pathnames to be truly useful.
CURRENT PRACTICE:
CLtL acknowledges this problem and declares it to be a system dependent
issue.
ADOPTION COST:
This should be a simple addition to implement.
BENEFITS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent. Relative pathnames could be trivially
specified by pathnames lacking a :DIRECTORY field.
CONVERSION COST: This is an upwards-compatible addition.
AESTHETICS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent.
DISCUSSION: >>Additional arguments, discussions, endorsements,
testimonials, etc. should go here.<<
∂16-Jul-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: Pathname-subdirectory-list
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87 17:14:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194405; Thu 16-Jul-87 20:14:29 EDT
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa@Xerox.COM, Ghenis.pasa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870715-132705-3165@Xerox>
Message-ID: <870716201416.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
I agree with the problem description. We've been dealing with heterogeneous
network for quite some time and have run into the same thing.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.
The solution to this problem that Symbolics has used for years works
quite well. The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level. In
addition to strings, in our system we allow certain keywords in the
list, enumerated below. Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.
When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted. To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.
In case those keywords aren't self-evident, here are some examples.
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.
(make-pathname :host "vixen"
:directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
:directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
:directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
:directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
:directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"
I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:
(make-pathname :host "dumbo"
:directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
:directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"
The name of the VMS host is not intended to be particularly pejorative, all of our
Vaxes are named after flying critters.
∂16-Jul-87 1730 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87 17:27:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194407; Thu 16-Jul-87 20:19:38 EDT
Date: Thu, 16 Jul 87 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870713-131840-2151@Xerox>
Message-ID: <870716201931.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
The new version looks okay to me.
∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:30:44 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:26:35 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05223; Fri, 17 Jul 87 11:45:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00220; Fri, 17 Jul 87 11:49:11 PDT
Date: Fri, 17 Jul 87 11:49:11 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171849.AA00220@bhopal.edsel.uucp>
To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu
Cc: labrea!Common-Lisp%sail@labrea.stanford.edu,
labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87 19:45:12 PDT <8707150245.AA03095@hpai00>
Subject: Apropos case sensitive?
[Note: LUCIDites are now using another mail gateway: typical address is:
edsel!jonl@labrea.stanford.edu]
Our reasoning here at Lucid was similar to what you came up with -- namely
that the language of CLtL, p. 443, very strongly implied the same semantics
of macthing as the default for SEARCH, which is an EQL, rather than an
EQUALP, test.
Many of us also felt the need so strongly for a case-insensitive apropos
that Lucid Common Lisp actually has two such functions hidden inside it:
lucid::case-insensitive-apropos
lucid::case-insensitive-apropos-list
but they will probably be "shaken" out in the delivered 2.1 beta images.
I feel that this issue should be presented to the "cleanup" sub-committee
of the X3J13 standards committee. Perhaps SEF can prod Steve Handerson
into writing up a proposal to them? Lucid might feel impelled to "expose"
this hidden function if the committe were inclined towards the proposal.
By the way, there are some other issues about apropos that might need
"cleaning up", some of which were discussed on this list a couple of
years ago (for "couple" mabye equal to one). For example, the
documentation uses the term "available symbols", but in at least one
instance, it ought to use "accessible symbols", for conformity to
chapter 11 on packages. Also, the scope of do-all-symbols has been
questioned by some; there have been at least two proposals on it:
(1) to add a new "function" called, say do-most-symbols, that excluded
certain packages
(2) to add a global variable (or a special variable) called, say,
*all-symbols-exclusions* which is a list of packages which the
several "all-symbols" functions would skip [e.g., do-all-symbols,
find-all-symbols, apropos, case-insensitive-apropos, etc]
-- JonL --
∂23-Jul-87 1735 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:50:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:50:14 PDT
Date: 23 Jul 87 15:49 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
Subject: Issue: LOAD-TIME-EVAL (Version 2)
Message-ID: <870723-155014-1175@Xerox>
The following from Jim Kempf:
Larry:
I've modified the proposal for LOAD-TIME-EVAL along the lines
suggested by Dave Moon and am resubmitting it. I'll keep the name of
the proposal at LOAD-TIME-EVAL, although LOAD-TIME-CONSTANT, as suggested
by Dave is probably a more appropriate name. SHARP-COMMA-SPECIAL-FORM
seems pretty much to be out, since the new proposal is for a functional
interface, rather than a special form.
Note that Dave's proposal will require more extensive modifications
in our system than a macro or special form; however, I believe it is
more elegant, since it avoids introducing a new special form (one of
the original goals of Common Lisp), and therefore more appropriate.
Jim Kempf kempf@hplabs.hp.com
!
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: Version 2 submitted 7/17/87, James Kempf.
Problem description:
The specification of #, (load time evaluation) in Common Lisp provides
a means, during compilation, of arranging for the evaluation of a
quoted or (in some implementations) unquoted form within embedded forms
processed by the reader, when the compiled file is loaded.
Inhibition of processing when a file is loaded into the interpreter
is possible using (EVAL-WHEN (LOAD) ... ). Code which is returned
during macroexpansion, however, is not processed by the reader, so
there is no way to arrange for deferral of processing until compiled
file load time in macroexpanded code.
Proposal (LOAD-TIME-EVAL:MAKE-LOAD-TIME-EVAL):
(MAKE-LOAD-TIME-EVAL <quoted form> &ENVIRONMENT env) : function
When processed by the interpreter or when encountered during evaluation
of the COMPILE function, the <quoted form> is evaluated once (and only
once) and the result is returned. When processed during a file
compilation, arrangement is made for the <quoted form> to be
evaluated when the compiled file is loaded, and the result returned.
Note that determining when file compilation is occurring and the details
of arranging for deferral of further processing until compiled
file load time are necessarily implementation dependent.
Test Case:
(defmacro print-load-date (&environment env)
`(quote ,(make-load-time-eval '(format T "~A~%" (get-date) env))))
When interpreted or processed during invocation of COMPILE, this
macro expands into code which prints the return value of the GET-DATE
function (presumed, for purposes of this example, to be a human
readable date) to *STANDARD-OUTPUT*. When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded.
Rationale:
Currently, there is no portable way to arrange for code returned
from a macro to defer evaluation until load time.
Current practice:
Currently, every version of Common Lisp is required to implement
compiler hooks for #, but, since this is only recognized by
reader, there is no portable way to achieve the same effect. Users
of Portable CommonLoops are encouraged to implement something similar.
Adoption Cost:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-EVAL may already exist, in others, more substantial
changes may be required.
Cost of non-adoption:
There are numerous possible uses for this facility. Version control
and system building facilities (such as the example) and optimization
of method invocation in the Common Lisp Object System come immediately
to mind. While every implementation of Common Lisp could certainly
provide an implementation specific facility, portability would suffer.
Benefits:
Portability. May make extensions to the Common Lisp Object system
via. the metaobject protocol easier.
Conversion Cost:
Most applications developers should not see much difference.
Esthetics:
The proposal fills a hole in the spectrum of alternatives for deferring
evaluation until a compiled file is loaded. Currently, code which is
read by the reader can arrange for it to be done, as can top level code,
but embedded code cannot.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp, but only a set of informal rules and various implementations.
Those implementations which have the primitives available should be
able to implement MAKE-LOAD-TIME-EVAL with little change to their
kernels, those which don't may require more extensive modifications.
∂23-Jul-87 1735 Masinter.pa@Xerox.COM Status, clarification list, members
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:54:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:54:24 PDT
Date: 23 Jul 87 15:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, clarification list, members
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870723-155424-1184@Xerox>
First, I want to apologize again for the delay in getting out the list
of clarifications & issues. I feel like it is important to merge in the
discussion with the work Scott Fahlman did in January of this year. I'm
still working on this list.
I've added Dieter Kolb, Siemens, Germany to the distribution list.
Siemens has a mail connection to Xerox, and Dieter can get arpanet mail
addressed to cl-cleanup, but, due to some technical and administrative
problems, I will have to forward his mail to the distribution list.
I will be adding another EuLisp committee member to cl-cleanup as well.
Part of our goal is to make sure that the EuLisp community is well
represented in the cleanup process.
∂24-Jul-87 1024 KMP@STONY-BROOK.SCRC.Symbolics.COM OPEN-KEYWORDS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:24:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198555; Fri 24-Jul-87 13:25:34 EDT
Date: Fri, 24 Jul 87 13:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724132524.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: OPEN-KEYWORDS
References: Pages 420-422
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 07/17/87
Problem Description:
The :if-exists and :if-does-not-exist arguments interact, but keyword
arguments should generally be orthogonal.
Proposal (OPEN-KEYWORDS:ORTHOGONAL):
Delete the following phrases from the first 2 paragraphs on page 422:
", or if the :if-exists argument is :overwrite or :append" and
", and the if-exists argument is anything but :overwrite or :append"
Test Case:
The following piece of code causes an error to be signaled:
(open "test" :direction :output :if-exists :overwrite)
if a file named "test" -doesn't- already exist.
With the change in this proposal, it wouldn't be an error.
Rationale:
As is clear from the test case example, a user might want to specify
that a certain action get taken in the case that a file already
exists, without affecting what happens in the case that it doesn't
exist. There is no good reason for the two cases to affect each
other.
Current Practice:
Adoption Cost:
Slight.
Benefits:
More sensible, easier to understand, more efficient to use and to
implement.
Conversion Cost:
Slight, automatable.
Esthetics:
Keyword arguments are supposed to be orthogonal, thus this deviation
is unaesthetic. It being so contrary to intuition makes it particularly
difficult for new LISP users to grasp.
Discussion:
∂24-Jul-87 1038 KMP@STONY-BROOK.SCRC.Symbolics.COM Mail from Skona Brittain
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:38:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198567; Fri 24-Jul-87 13:39:24 EDT
Date: Fri, 24 Jul 87 13:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Mail from Skona Brittain
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724133919.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The OPEN-KEYWORDS proposal which I just sent arrived in my hardcopy mailbox
today. I passed it through completely unedited; in fact, I didn't have time
to read it while I was typing. I'll comment later when I've had time.
There was also a cover letter that said:
... I still have not been able to do much of anything with my account.
I tried to send mail but kept getting "no such local user" messages,
even when just directly responding to a test message from a non-local
friend. Nor have i received any X3-J13 mail at all yet. So if you want
to respond to this, I would appreciate your trying my netmail address,
but if your mail gets returned, please use [P.O. Box 747, Santa Barbara,
CA 93102; (805) 963-3412].
Regarding the order of arguments' evaluation, as in the
push-evaluation-order proposal, I still believe that this is specified in
CLtL. I mentioned the reference on page 97 to "the usual left-to-right
order in which the various subforms are evaluated" but have since found
a less oblique one: the entire last half of page 99.
It is my impression that there needs to be a clarification of the
effect of *print-level* and *print-length*, so if this impression is
correct, I will volunteer to write it up. Basically, there seems to be a
confusion about whether it is the actual components of the object that
count or what the object looks like when printed in list notation. For
example, the levels of 'x and (quote x) are considered different (cf
page 373) but string-char arrays of rank >1 are affected by
*print-length* even when printed in non-list notation (cf page 369).
Other cases that are affected by this distinction include
- a structure with n components has 2n+1 elements in its printed list
representation
- nil vs. ()
- a rank 0 array has a component but prints with no parentheses whereas
a 0xN array has 2 levels of parens and no components, etc.
Since I am obviously not as well-qualified as the rest of the
clean-up committee to judge such issues, and since I don't have access
to any other preliminary feedback, there does not seem to be much point
in my proceeding with writing up something like this until further
notice.
A suggestion for a change that I have is that some of the defstruct
arguments be strings instead of symbols, but I also don't know if
there's any point in entertaining it.
I was under the impression at the meeting Monday that thecleanu-up
committee was going to suggest setting up several other committees,
including one on the file systems handling, but when I reminded Larry on
Wednesday, he said there weren't any that hadn't already been set up, so
I am unsure of the status of the situation regarding a file
subcommittee. ...
∂27-Jul-87 1005 KMP@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87 10:05:12 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 199647; Mon 27-Jul-87 13:02:54 EDT
Date: Mon, 27 Jul 87 13:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last list given to
append is discarded (whether NIL or not) when constructing the new list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Test Case:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
[Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).]
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Adoption Cost:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND incompatibly,
the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND to expect only NIL
when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Benefits:
Since non-lists are allowed as a last argument and since APPEND can
therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND can reliably deal in general with dotted lists,
something that doesn't appear to be guaranteed by a strict reading. The
proposed extension would happen to legitimize such assumptions.
Conversion Cost:
This change is "upward compatible".
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between
lists and dotted lists. Those who view dotted lists as a special kind
of list may feel differently than those who view lists as a special
kind of dotted list.
Discussion:
KMP supports the proposed extension.
∂27-Jul-87 1754 FAHLMAN@C.CS.CMU.EDU APPEND-DOTTED
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 17:54:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 20:54:00-EDT
Date: Mon, 27 Jul 1987 20:53 EDT
Message-ID: <FAHLMAN.12321826393.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: APPEND-DOTTED
In-reply-to: Msg of 27 Jul 1987 13:02-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
This looks good to me.
-- Scott
∂27-Jul-87 1802 FAHLMAN@C.CS.CMU.EDU [Fahlman: Iteration standard]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 18:02:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 21:02:34-EDT
Date: Mon, 27 Jul 1987 21:02 EDT
Message-ID: <FAHLMAN.12321827954.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Fahlman: Iteration standard]
This is not really cleanup committee business. I just thought that it
might be of interest to some of you...
Date: Thursday, 23 July 1987 21:15-EDT
From: Scott E. Fahlman <Fahlman>
To: loop-groop%clam at SUN.COM
cc: fahlman
Re: Iteration standard
OK, apparently this is the proper address for iteration discussions.
Here's what I wanted to say (probably an anticlimax at this point):
In the past, I have always been a vocal opponent of adopting the MIT
LOOP macro, or anything very close to it, as a part of the Common Lisp
standard. I think that the basic functionality of LOOP is OK, and I've
got no real problem with its lack of a clean unifying abstraction; my
objection was that the cute, non-Lispy, pseudo-English infix/keyword
syntax was confusing and not in keeping with the rest of the language or
the direction in which Lisp should be moving. My hope was that if we
stalled this decision for a while, someone would come up with something
better and that that "something better" would catch on in some
significant segment of the community. (This strategy turned out to be a
good one with respect to object-oriented programming and old-style
flavors.)
Well, I've mellowed on this. Personally, I would still rather see
something like
(loop (for i 0 100 2)
(while (non-prime-p (foobar i))
(collect (flowers-in-may))
(finally (print *famous-last-words*)))
than the non-parenthesized run-on sentence equivalent, but we've been
hung up on this difference of opinion for five years and I'm ready to
throw in the towel. Nothing else has caught on, and in the meantime
LOOP has consolidated its position and started to spread. It IS better
than nothing. The people who use it seem to like it. When
pretty-printed properly it is readable enough -- I can blur my eyes and
pretend that the missing parens are there.
So, speaking only for myself, I would be willing to accept and even
support LOOP or something very similar as long as (1) it is cleanly
defined and (2) someone provides a portable, efficient public-domain
implementation. In my view, it's time to settle this and move on.
Of course, I can't speak for the other people who still find LOOP syntax
disgusting. Maybe some of the others are ready to compromise as well.
I was discussing this with Stan Shebs of Utah -- another former LOOPS
hater, probably because he was a fan of PSL's FOR macro -- and he was
also ready to bow to the inevitable. Those who favor a more uniform and
principled approach to the whole iteration business -- the fans of LetS,
for example -- may be harder to please.
-- Scott
∂30-Jul-87 1129 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 87 11:28:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202848; Thu 30-Jul-87 14:29:55 EDT
Date: Thu, 30 Jul 87 14:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870713-141108-2238@Xerox>
Message-ID: <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 Jul 87 14:05 PDT
From: Masinter.pa@Xerox.COM
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
In some CLOS stuff I'm writing today, I'm using the terms "positional
argument" and "named argument". Positional arguments are received by
required and optional parameters, while named arguments are received
by &key parameters. &rest parameters can receive either kind of argument.
I don't have time to revise the proposal today, but perhaps I can do
so along these lines later, if people agree that this is a good
terminology.
∂30-Jul-87 1145 FAHLMAN@C.CS.CMU.EDU Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 87 11:44:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jul 87 14:44:49-EDT
Date: Thu, 30 Jul 1987 14:44 EDT
Message-ID: <FAHLMAN.12322545615.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: Msg of 30 Jul 1987 14:29-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Seems like a good terminology to me, though you'll have to define your
terms at the start of the proposal so that nobody has to guess exactly
what you mean.
-- Scott
∂30-Jul-87 1717 Masinter.pa@Xerox.COM Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 87 17:16:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 87 17:16:56 PDT
Date: 30 Jul 87 17:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 30 Jul 87 14:29 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870730-171656-1501@Xerox>
While I think that "positional" and "named" are good ways of talking
about the different kinds of arguments, and that "key arguments" is
awkward, I don't think it is necessary for you to spend your time
rewriting the proposal KEYWORD-ARGUMENT-NAME-PACKAGE, which doesn't
make any recommendations about terminology in the standard; rather, it
just uses it locally.
I would like to see a set of "terminology" recommendations for the spec
gathered and passed by X3J13; there are a number of other things which
have passed through here that would belong in it. I don't think they fit
into the standard form for language changes (since the considerations
are different, e.g., "current practice" might refer to existing
textbooks and programming language literature).
∂31-Jul-87 1833 edsel!bhopal!jonl@labrea.stanford.edu Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 18:33:28 PDT
Received: by labrea.stanford.edu; Fri, 31 Jul 87 18:22:00 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA04329; Fri, 31 Jul 87 18:22:15 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA06397; Fri, 31 Jul 87 18:19:33 PDT
Date: Fri, 31 Jul 87 18:19:33 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708010119.AA06397@bhopal.edsel.uucp>
To: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 30 Jul 87 14:29 EDT <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
I too like this terminology, and think that changing it now is an important
thing to do, despite the five years of "keyword arguments."
By the way, as an English phrase, "&key parameters" leaves me a bit cold.
How about "positional parameters" and "named parameters" , to parallel
"positional arguments" and "named arguments"?
-- JonL --
∂05-Aug-87 1931 Moon@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Aug 87 19:30:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207665; Wed 5-Aug-87 21:35:47 EDT
Date: Wed, 5 Aug 87 21:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870805213544.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve.
∂14-Aug-87 1651 unido!ztivax!kolb@seismo.CSS.GOV Redefinition of system functions
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 14 Aug 87 16:51:10 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA13396; Fri, 14 Aug 87 19:51:00 EDT
Received: by unido.uucp with uucp;
Fri, 14 Aug 87 16:01:15 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Date: Fri, 14 Aug 87 15:06:16 -0100
Message-Id: <8708141406.AA04604@ztivax.uucp>
Received: by ztivax.uucp; Fri, 14 Aug 87 15:06:16 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Redefinition of system functions
Problem description:
CLtL allows the redefinition of functions exported from other packages.
Unexperienced programmers may redefine a system function unintentional
which may result into an inconsistent state of the system and cause to
abort.
This happens, for example, if a beginner follows the CL introductory
book "Essential LISP" by Anderson et.al. page 41 where an exercise asks
to define a function make-list. After the redefinition of make-list the
system crashs without returning a message that the function has been
redefined.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Solution:
Redefinition of exported functions should stay allowed. However, some
functions - especially all functions of the package LISP - should be
protected from redefinition. In the case a user tries to redefine such a
function a confirmation should be required.
Protected user functions can be specified in a special list (look-up-
table, value of the variable *protected-functions-from-redefinition*).
Functions from package LISP are protected per se and have not to be
added into this list.
There should be two functions to add and to remove an entry to/from this
list:
protect-function-from-redefinition name
release-function-for-redefinition name
The only function involved in protecting functions from redefinition
seems to be defun. Advising (in the sense of Interlisp) protected
functions, however, should stay allowed.
Dieter Kolb
∂14-Aug-87 2055 FAHLMAN@C.CS.CMU.EDU Redefinition of system functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 20:54:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Aug 87 23:54:46-EDT
Date: Fri, 14 Aug 1987 23:54 EDT
Message-ID: <FAHLMAN.12326577897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dieter Kolb <unido!ztivax!kolb@SEISMO.CSS.GOV>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Redefinition of system functions
In-reply-to: Msg of Fri 14 Aug 87 15:06:16 -0100 from Dieter Kolb <unido!ztivax!kolb at seismo.CSS.GOV>
If there are functions whose redefinition would destroy a particular
Lisp system, I wouldn't mind getting a warning and perhaps even a
correctable error from DEFUN if I am about to lose. The set of
protected functions might include all of the built-in Common Lisp
functions, or it might be a small subset, depending on the details of
the implementation.
There must be a way to turn this protection off, however -- some people
know what they are doing and don't want Lisp to save them. Advising is
one such case, patching over bugs in the built-in functions is another,
and turning a built-in function into a CLOS generic function so that new
behaviors can be added for new types is yet another (once we decide how
much of this will be allowed).
In any case, I think that such protection probably should be considered
an programming-environment issue that is left up to each implementor.
Is there any real need for a standard solution here? I suppose we do
need to make clear that randomly modifying the built-in functions is not
something that is allowed in strictly legal Common Lisp programs.
-- Scott
∂24-Aug-87 1138 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:38:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219273; Mon 24-Aug-87 14:33:31 EDT
Date: Mon, 24 Aug 87 14:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 1)
To: Cl-Cleanup@sail.stanford.edu
References: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU>
Message-ID: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION
Edit history: Moon 24 Aug 87 new issue (version 1)
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
Proposal SHADOW-ALREADY-PRESENT:WORKS: The SHADOW function always adds
the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is
already present in the package.
Test Case:
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
Rationale:
Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol. For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.
Current practice:
[I have not confirmed any of these myself except Symbolics --Moon]
Symbolics and Spice Lisp behave as proposed here. Kyoto Common Lisp
behaves the other way. Kolb implied, but did not state explicitly,
that Lucid Common Lisp and Xerox Common Lisp behave like KCL. It seems
likely that we will find several implementations in each camp.
Adoption Cost: It should be a one-line change in one function.
Cost of non-adoption: Inconsistency among implementations and lack of a
clear way to resolve the name conflict mentioned in Rationale.
Benefits: Consistency.
Conversion Cost: Technically this would be an incompatible change to
implementations that do not already behave as proposed, however it is
difficult to conceive of a user program that would require any
conversion to cope with the change. Some users might want to remove
kludges that were only necessary to get around the misbehavior of
SHADOW.
Esthetics: The proposal would remove an unnecessary special case,
thus simplifying the language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
∂24-Aug-87 1808 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 18:07:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 24 Aug 87 21:08:04-EDT
Date: Mon, 24 Aug 1987 21:08 EDT
Message-ID: <FAHLMAN.12329168991.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Cl-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: SHADOW-ALREADY-PRESENT (version 1)
In-reply-to: Msg of 24 Aug 1987 14:33-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I'm in favor of SHADOW-ALREADY-PRESENT:WORKS.
Thanks to Moon for writing this up so quickly.
-- Scott
∂27-Aug-87 1429 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87 14:28:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 222476; Thu 27-Aug-87 17:30:06 EDT
Date: Thu, 27 Aug 87 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 2)
To: Cl-Cleanup@sail.stanford.edu
cc: Jon L White <edsel!bhopal!jonl@labrea.stanford.edu>
References: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870827172932.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION
Edit history: Moon 24 Aug 87 new issue (version 1)
Moon 27 Aug 87 incorporate suggestions from JonL (version 2)
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
SHADOW is said to take symbols as arguments, however only the print-name
is meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. In addition,
the first argument is allowed to be or contain strings as well as symbols.
The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
To test the use of strings in place of symbols, change the
third line of the test case to
(shadow "TEST" (find-package 'test-1))
Note the use of capital letters in the string.
Rationale:
Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol. For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.
Since only the print name of a symbol argument is meaningful, a string
should also be accepted. This is particularly useful to avoid problems
when compiling code in one package environment and loading it into a
slightly different package environment, where the symbol that was referred
to at compile time may not be present at load time. This is particularly
important because the symbol referred to by the print name may be changed
by evaluation of the SHADOW form. A close reading of CLtL shows that one
can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much
the same effect as (shadow "BAR"). But the user should not have to play
such games, strings should be accepted.
Current practice:
[I have not confirmed any of these myself except Symbolics --Moon]
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. Kyoto Common
Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the
symbol is already present in the package. It seems likely that we will
find several implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Adoption Cost:
It should be two one-line changes in one function.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the
name conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Conversion Cost:
Technically this would be an incompatible change to implementations that do
not already behave as proposed, however it is difficult to conceive of a
user program that would require any conversion to cope with the change.
Some users might want to remove kludges that were only necessary to get
around the former misbehavior of SHADOW.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
Epigram:
"Who knows what evil lurks in the hearts of men?"
∂29-Aug-87 1337 Masinter.pa@Xerox.COM [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Aug 87 13:36:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 87 13:36:54 PDT
Date: 29 Aug 87 13:36 PDT
From: Masinter.pa@Xerox.COM
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: cl-cleanup@sail.stanford.edu
cc: Carnese@SPAR-20.ARPA
Message-ID: <870829-133654-4656@Xerox>
I've given the name "EXPORT-COORDINATION" to this issue. I think this is
an interesting proposal. Comments? (Before Dan writes up a more formal
proposal?)
----- Begin Forwarded Messages -----
Return-Path:
<@SPAR-20.ARPA,@KATYDID.SPAR.CAS.SLB.COM:Carnese@SPAR-20.ARPA>
Received: from SPAR-20.ARPA by Xerox.COM ; 25 AUG 87 13:01:17 PDT
Received: from KATYDID.SPAR.CAS.SLB.COM (KATYDID.#Internet) by
SPAR-20.ARPA with TCP; Tue 25 Aug 87 12:59:13-PDT
Date: Tue, 25 Aug 87 12:59 PDT
From: Dan Carnese <Carnese@SPAR-20.ARPA>
Subject: proposal
To: masinter.pa
Message-ID: <870825125906.2.CARNESE@KATYDID.SPAR.CAS.SLB.COM>
Thanks for the information. I didn't realize that proposals were
required
to be in such a detailed format but of course that makes sense.
I think the problem can be "symbolized" as
multiple-forms-for-exported-defined-symbols. Its definition could be:
Exporting a defined symbol currently requires two seperate
forms:
one to give a value to the symbol and another to cause the
symbol
to be on a package export list. These two forms must be kept in
sync as the program evolves.
The benefit would be:
Explicit export lists could be eliminated in many cases.
The thrust of the discussion would be:
This is an extremely straightforward addition, one which could
be
implemented by macros that would simply expand to an export and
an
existing definition form. Only DEFSTRUCT* would involve actual
programming, to process the additional defstruct and slot
options.
The proposal does not completely eliminate the need for explicit
calls to EXPORT for two reasons. First, it is sometimes useful
to
export symbols for which no definition forms are applicable,
e.g.,
to be used as arguments to functions. Second, explicit exports
of
defined symbols are still needed in the following case. Suppose
A
and B are packages, A defines an external symbol F, and B uses
A.
Suppose further that F appears in a form being read into package
B,
and that this form is to be read before the definition of F is
loaded. In this case, an explicit export of F must occur, to
avoid
F being inappropriately interned in B.
Does this sound reasonable?
-- Dan
----- End Forwarded Messages -----
∂29-Aug-87 1439 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Aug 87 14:39:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 29 Aug 87 17:40:55-EDT
Date: Sat, 29 Aug 1987 17:40 EDT
Message-ID: <RAM.12330441992.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: Carnese@SPAR-20.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 29 Aug 1987 16:36-EDT from Masinter.pa at Xerox.COM
The idea has obvious intuitive appeal, since people tend to think of
exporting definitions rather than names. Unfortunately, I think that
there is likely to be some messy semantics due to name resolution
happening at read time and the implicit package manipulation happening
later on. The semantics of package manipulation with respect to
compile-file/load is currently not defined. [Except perhaps in some
vague language that suggests the semantics of loading the source are
preserved, which is clearly wrong.] It is certainly naive to suppose
that a macro can expand into arbirary package manipulation code and
"the right thing" will happen.
I think that exporting symbols from the current package happens to be
safe as long as all the code in a file is restricted to one package,
but I certainly don't want to have to figure out which of all possible
kinds of package manipulation will break what possible reasonable
compiler organizations.
You should also be careful that you aren't thinking of this issue in
terms of "top-level defining forms", since I am convinced that the
notion of a "top-level form" is semantically bankrupt. Although some
forms are most often used at "top-level" (however defined), the
semantics of those forms are a result of its evaluation, and a form can
be evaluated anywhere. Consider the semantics of:
(if <whatever>
(defun-exported foo ...))
Consider the possible range of implementations such as "compilers" and
"interpreters". Is Foo {always | never | sometimes} exported at
{read | macroexpand | compile | load | run} time?
I currently favor requiring all package manipulation to be done at the
head of the file. This has the advantage that it allows compilers and
editors to find all stuff pertinent to read-time semantics without
having to go through the motions of compiling the entire file.
Of course, it would be possible to have an automatic exporting feature
without allowing users to have package-hacking macros.
Rob
∂02-Sep-87 1926 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 2 Sep 87 19:26:25 PDT
Date: Wed 2 Sep 87 19:25:58-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12330441992.BABYL@>
Message-ID: <12331542476.10.CARNESE@SPAR-20.ARPA>
Although not explicitly stated in the message Larry forwarded, the proposal
is for def...* forms that export the defined symbols from their packages.
Of course, your observations are valid about the non-clarity of the value
of *package* and of when a symbol is actually defined. But they don't seem
directly relevant to this proposal, since they describe problems in the
current language definition. So long as the export occurs just after the
cell is filled, I don't think we're adding to the existing murkiness.
-------
∂02-Sep-87 1952 FAHLMAN@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 19:52:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Sep 87 22:52:27-EDT
Date: Wed, 2 Sep 1987 22:52 EDT
Message-ID: <FAHLMAN.12331547288.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
I'll stay out of the argument about whether it is a good idea to scatter
the exports (implicit or explicit) all through the file, rather than
requiring all the exports to occur at the start of each file. This is
tied up with some big questions about the compiler, and it can't really
be settled in isolation.
Just for the record, though, I would strongly oppose any proposal to use
DEF...* for naming the def-exporting forms. The last thing we need in
this language is to start sticking stars and other meaningless
decorations on the end of symbols whenever we want to say "different in
some way that I know and you'll have to guess". There's already some of
this kind of thing in the language, held over from other Lisps, but we
shouldn't extend the practice.
-- Scott
∂03-Sep-87 1118 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 11:17:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
Date: Thu, 3 Sep 1987 14:17 EDT
Message-ID: <RAM.12331715786.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
Actually, having the defining form export the symbol from its home
package is more problematic than exporting from the current package.
Consider a code fragment like:
(in-package 'a :use '(lisp b))
...
(defun-exported b::foo ...)
foo
What package is the following "foo" in? Obviously the DEFUN-EXPORTED
and the "foo" could be in the same form, so under some circumstances,
that "foo" couldn't possibly refer to B:FOO, yet if the compiler
happened to process the DEFUN-EXPORTED before the "foo" was read, then
it would be B:FOO.
To say that these things are "just problems in the current language
definition" doesn't avoid the problem. Adding new langauge features
is language design, and a language designer must consider how each
language feature will affect his ability to properly define the
language. I am suggesting that this feature would significantly
complicate the language definition for what seems to me to be little
gain.
Rob
∂04-Sep-87 1030 edsel!bhopal!jonl@labrea.stanford.edu [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:30:27 PDT
Received: by labrea.stanford.edu; Fri, 4 Sep 87 10:11:04 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
id AA22223; Fri, 4 Sep 87 09:08:33 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA04816; Fri, 4 Sep 87 09:08:14 PDT
Date: Fri, 4 Sep 87 09:08:14 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8709041608.AA04816@bhopal.edsel.com>
To: labrea!Ram%C.CS.CMU.EDU@labrea.stanford.edu,
labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!CARNESE%SPAR-20.ARPA@labrea.stanford.edu,
labrea!cl-cleanup%SAIL@labrea.stanford.edu
In-Reply-To: navajo!Ram@C.CS.CMU.EDU's message of Thu, 3 Sep 1987 14:17 EDT <RAM.12331715786.BABYL@>
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
One of the good qualities I liked about Mesa (the Xerox answer to Pascal)
was the way programmers were encouraged to write a "defs" file for every
"module" -- basically, this file declares the exportable items, along with
their syntax (no code, however), and also mentions the importations (a bit
like CL's REQUIRE). I don't know how much of a pain it was for programmers
to produce correct modules under this regimen, but it sure made it a heck
of a lot easier to read someone else's code.
I, for one, in my regular work wind up reading a lot of other people's
code; and most of my code is eventually read by other people. Hence I
would prefer a direction for Common Lisp which facilitated the ability
to read other people's code, even at the expense of some programming
conveniences. This means that having all the "7 extrememly randoms"
at the beginning of a file (except for PROVIDE) is a much better
solution than having them sprinkled around random other files in
random other modules.
-- JonL --
∂04-Sep-87 1047 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:47:43 PDT
Date: Fri 4 Sep 87 10:15:49-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12331715786.BABYL@>
Message-ID: <12331966613.10.CARNESE@SPAR-20.ARPA>
Return-Path: <RAM@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SPAR-20.ARPA with TCP; Thu 3 Sep 87 11:18:03-PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
Date: Thu, 3 Sep 1987 14:17 EDT
Message-ID: <RAM.12331715786.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
Actually, having the defining form export the symbol from its home
package is more problematic than exporting from the current package.
Consider a code fragment like:
(in-package 'a :use '(lisp b))
...
(defun-exported b::foo ...)
foo
What package is the following "foo" in? Obviously the DEFUN-EXPORTED
and the "foo" could be in the same form, so under some circumstances,
that "foo" couldn't possibly refer to B:FOO, yet if the compiler
happened to process the DEFUN-EXPORTED before the "foo" was read, then
it would be B:FOO.
To say that these things are "just problems in the current language
definition" doesn't avoid the problem. Adding new langauge features
is language design, and a language designer must consider how each
language feature will affect his ability to properly define the
language. I am suggesting that this feature would significantly
complicate the language definition for what seems to me to be little
gain.
Rob
Sorry, but I'm still not clear on how this extension makes the situation
any more complicated. What I understand you to be saying is that the
semantics of your example would not be well-defined in the case where these
are not top-level forms. Of course, you're right. But since any code
involving the new constructs can be expanded into existing constructs
(e.g., by replacing the defun-exported with a defun followed by an export),
the proposal doesn't introduce any new kinds of problematic situations.
Thus, it is difficult to argue that the language definition would be made
more complicated by having such expansions predefined.
With regard to the naming issue that Scott raised, the use of "-exported"
as a suffix seems quite reasonable. I'm happy to accede to a change that
increases readability.
-------
∂21-Sep-87 1436 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:36:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238094; Mon 21-Sep-87 17:37:55 EDT
Date: Mon, 21 Sep 87 17:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
To: CL-Cleanup@sail.stanford.edu
Supersedes: <870921172903.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870921173659.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SETF-METHOD-FOR-SYMBOLS
References: CLtL pp. 105, 99
Category: CHANGE
Edit history: Version 1 Moon 21 Sep 87
Problem description:
The description of SETF in CLtL is inconsistent in that page 99
requires side-effects to be elaborated in left-to-right order,
while page 105 specifies a setf-method for symbols that makes
it impossible to implement this in some cases, such as the test
case given below (provided by Timothy Daly of IBM).
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the result of (get-setf-method 'foo) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
to
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
Test Case:
Given
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
If side-effects are elaborated in left-to-right order,
the setq of R to NIL should not affect the result, since
it occurs after R is read and before R is written, and
therefore the value of both R and S should be (A 1 B 6 C 3).
A typical result in an implementation that believes CLtL p.105
more than CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).
Rationale:
The general principle mentioned on p.99 should override the
specific example on p.105. The latter is probably just a mistake.
Current practice:
Symbolics and Lucid return the incorrect result mentioned in the test
case above. Franz returns something else: r = nil and s = (a 1 b 6 c 3).
Symbolics plans to fix this in the next release.
Adoption Cost:
SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some
care might be required in updating implementations. However, in
some implementations changing what get-setf-method returns when its
argument is a symbol is the only change required.
It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.
Cost of non-adoption:
Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.
Benefits:
The opposite of what I just said.
Conversion Cost:
This change is incompatible because it changes the result of some forms
that are not erroneous. However, it's unlikely that very many users are
intentionally depending on the current behavior. In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.
Esthetics:
See "cost of non-adoption".
Discussion:
I wish CLtL did a much better job of explaining the philosophy of SETF,
and included some better examples of precisely what is meant by the
"`obvious' semantics" mentioned on page 99. I will accept some of the
blame for this lack in the documentation. --Moon
∂21-Sep-87 1957 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87 19:56:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Sep 87 22:57:14-EDT
Date: Mon, 21 Sep 1987 22:57 EDT
Message-ID: <FAHLMAN.12336528894.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 21 Sep 1987 17:36-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I tried Daly's example in Spice Lisp, and it gave what Moon proposes as
the intuitive answer: both R and S end up with (A 1 B 6 C 3). And in
the same Lisp, (get-setf-method 'foo) returns the values prescribed in
CLtL: nil nil (#:G1) (setq foo #:G1) foo. So the statement in Moon's
proposal that Daly's example is impossible to implement with with this
set of values is false. There might be other examples which dictate the
change in get-setf-method that Moon proposes, but this particular
case does not force the issue.
The trick here is that the get-setf-method value-set for Getf sets up
all of the necessary bindings, rather than doing this in the method for
a symbol:
(get-setf-method '(getf a b)) =>
(#:G1 #:G2)
(A B)
(#:G3)
(progn (setq #:G1 (%putf #:G1 #:G2 #:G3))
(setq A #:G1)
#:G3)
(getf #:G1 #:G2)
Is there some problem here I don't see?
For what it's worth, I get the following:
(setf (getf (nthcdr 2 r) 'b) (progn (setq r nil) 6))
r = nil, s = (a 1 b 6 c 3)
(setf (nthcdr 2 r) (progn (setq r nil) 6))
r= nil, s = (a 1 . 6)
I think that these values are right, since changing the tail of the old
value of R can't set anything back into R to override the explict SETQ.
Anyone disagree? Our code gets no failures trying to setq the nthcdr of
nil, or whatever.
Unless I'm missing something, I would say that these examples shoot down
Moon's proposal in its current form.
-- Scott
∂22-Sep-87 0756 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 87 07:55:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238559; Tue 22-Sep-87 10:57:35 EDT
Date: Tue, 22 Sep 87 10:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12336528894.BABYL@C.CS.CMU.EDU>
Message-ID: <870922105646.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 21 Sep 1987 22:57 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I tried Daly's example in Spice Lisp, and it gave what Moon proposes as
the intuitive answer: both R and S end up with (A 1 B 6 C 3). And in
the same Lisp, (get-setf-method 'foo) returns the values prescribed in
CLtL: nil nil (#:G1) (setq foo #:G1) foo. So the statement in Moon's
proposal that Daly's example is impossible to implement with with this
set of values is false. There might be other examples which dictate the
change in get-setf-method that Moon proposes, but this particular
case does not force the issue.
The trick here is that the get-setf-method value-set for Getf sets up
all of the necessary bindings, rather than doing this in the method for
a symbol:
(get-setf-method '(getf a b)) =>
(#:G1 #:G2)
(A B)
(#:G3)
(progn (setq #:G1 (%putf #:G1 #:G2 #:G3))
(setq A #:G1)
#:G3)
(getf #:G1 #:G2)
Is there some problem here I don't see?
Doesn't this only show that getf's setf-method is calling a private
copy of get-setf-method for the first argument, rather than recursively
calling the regular get-setf-method? If not, how did it know that a
temporary variable needed to be bound to a? Perhaps it just always
binds a temporary variable to any first argument; but then the difference
between the CLtL setf-method for variables and my proposed new one
is ignored by Spice Lisp in this case.
It's true that I shouldn't have said it was impossible to implement setf
correctly in the face of the setf-method prescribed by CLtL. I should
have realized that an implementation was free to introduce more
temporary variables than the ones implied by the setf-method. However,
consider this example, using the setf-method for ldb prescribed by CLtL
page 106:
(setq a 0)
(incf (ldb (byte 2 2) a) (setq a 2))
Does this leave a=8, a=10, or a=2? I believe 8 is what is intended by
page 99's statement about order of evaluation of subforms.
Note that no arguments about an implementation having its own setf method
for ldb are relevant here. If users are to be able to write hairy setf
methods in portable code, which I assume is a goal otherwise why did we
document all this stuff, then setf-methods written in the style of the
one CLtL gives for LDB have to work portably and produce equivalent effects
in all implementations.
For what it's worth, I get the following:
(setf (getf (nthcdr 2 r) 'b) (progn (setq r nil) 6))
r = nil, s = (a 1 b 6 c 3)
(setf (nthcdr 2 r) (progn (setq r nil) 6))
r= nil, s = (a 1 . 6)
I think that these values are right, since changing the tail of the old
value of R can't set anything back into R to override the explict SETQ.
I agree.
Anyone disagree? Our code gets no failures trying to setq the nthcdr of
nil, or whatever.
Unless I'm missing something, I would say that these examples shoot down
Moon's proposal in its current form.
Do you still think that after seeing my reaction above? If so, I think we
need to back off and consider precisely what CLtL p.99 was supposed to be
saying.
∂22-Sep-87 0854 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 08:54:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 11:54:13-EDT
Date: Tue, 22 Sep 1987 11:54 EDT
Message-ID: <FAHLMAN.12336670332.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 22 Sep 1987 10:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Well, here's our setf method for Getf. It clearly is not using some
private method to get symbols right, but is using the standard setf
method for whatever the first form is. It seems to me that the way it
is using the store variable from the first subform is fairly
straightforward, and doesn't introduce more temporaries than would be
needed under your scheme, but I could be wrong.
Can you show me the Getf method that would result from your proposed way
of handling the symbol values? Is it significantly simpler or more
efficient? When it comes to efficiency, I'd rather have a little extra
variable shuffling in Getf and places like that than in all setf's
involving a symbol destination.
(define-setf-method getf (place prop &optional default &environment env)
(multiple-value-bind (temps values stores set get)
(get-setf-method place env)
(let ((newval (gensym))
(ptemp (gensym))
(def-temp (gensym)))
(values `(,@temps ,(car stores) ,ptemp ,@(if default `(,def-temp)))
`(,@values ,get ,prop ,@(if default `(,default)))
`(,newval)
`(progn (setq ,(car stores)
(%primitive putf ,(car stores) ,ptemp ,newval))
,set
,newval)
`(getf ,(car stores) ,ptemp ,@(if default `(,def-temp)))))))
-- Scott
∂22-Sep-87 0905 FAHLMAN@C.CS.CMU.EDU Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 09:05:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 12:05:27-EDT
Date: Tue, 22 Sep 1987 12:05 EDT
Message-ID: <FAHLMAN.12336672387.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 22 Sep 1987 10:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Maybe we should fix the manual's definition for setf of ldb rather than
the values returned for symbol? Or if fixing ldb is really too hairy
under the current setf definition, maybe this shold be the example we
use in the cleanup proposal.
-- Scott
∂22-Sep-87 1253 Masinter.pa@Xerox.COM Re: APPEND-DOTTED
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 12:53:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 12:51:54 PDT
Date: 22 Sep 87 12:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: APPEND-DOTTED
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 27 Jul 87 13:02 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870922-125154-12438@Xerox>
(I'm *finally* back on CL-Cleanup related work; we must hustle to get
stuff out for the meeting. Sorry.)
In current practice, Xerox Common Lisp and Kyoto Common Lisp signal
errors on the proposed test case (both interpreted and compiled.)
There are notes in the ISSUES.TXT file:
Page 268:
The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g. (append '() t) => t.
Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.
Should this be added to this proposal?
∂22-Sep-87 1254 Masinter.pa@Xerox.COM [remailed] Re: APPEND-DOTTED
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 12:53:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 12:52:21 PDT
Date: 22 Sep 87 12:52 PDT
From: Masinter.pa@Xerox.COM
Subject: [remailed] Re: APPEND-DOTTED
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 27 Jul 87 13:02 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <870922-125221-12440@Xerox>
(I'm *finally* back on CL-Cleanup related work; we must hustle to get stuff out for the meeting. Sorry.)
In current practice, Xerox Common Lisp and Kyoto Common Lisp signal errors on the proposed test case (both interpreted and compiled.)
There are notes in the ISSUES.TXT file:
Page 268:
The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g. (append '() t) => t.
Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.
Should this be added to this proposal?
∂22-Sep-87 1300 dcm%hpfclp@hplabs.HP.COM Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:00:11 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 22 Sep 87 10:59:27 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 22 Sep 87 10:58:59 mdt
Return-Path: <dcm@hpfcdcm>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
X-Mailer: mh6.5
In-Reply-To: Your message of Mon, 21 Sep 87 17:36:00 -0400.
<870921173659.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 22 Sep 87 10:58:55 MST
Message-Id: <3760.559328335@hpfcdcm>
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
HP's Common Lisp produced the desired results, namely r and s having
identical values. I agree that this change would be beneficial to the
language and should not adversely impact the performance of most
implementations.
1 LISP [USER:] > (setq r '(a 1 b 2 c 3))
(A 1 B 2 C 3)
2 LISP [USER:] > (setq s r)
(A 1 B 2 C 3)
3 LISP [USER:] > (setf (getf r 'b) (progn (setq r nil) 6))
6
4 LISP [USER:] > r
(A 1 B 6 C 3)
5 LISP [USER:] > s
(A 1 B 6 C 3)
6 LISP [USER:] > (eq r s)
T
Dave Matthews
∂22-Sep-87 1303 Masinter.pa@Xerox.COM Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:03:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 13:03:35 PDT
Date: 22 Sep 87 13:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Dan Carnese <CARNESE@SPAR-20.ARPA>'s message of Fri, 4 Sep
87 10:15:49 PDT
To: CARNESE@SPAR-20.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870922-130335-12464@Xerox>
I think the discussion on cl-cleanup is inconclusive enough that the
next step on this proposal is to take it to the wider forum of
common-lisp@sail.stanford.edu. I don't think we're going to make a lot
more progress on it here. There are enough reservations about the
soundness of the programming style it encourages that I think it
requires a clearer mandate from the user community to justify a required
language extension.
Larry
∂22-Sep-87 1306 Masinter.pa@Xerox.COM Re: Issue: EVAL-DEFEATS-LINKER
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:06:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 13:06:49 PDT
Date: 22 Sep 87 13:06 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: EVAL-DEFEATS-LINKER
In-reply-to: various messages in june
To: cl-cleanup@SAIL.STANFORD.EDU
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870922-130649-12470@Xerox>
I think procedurally the proper mechanism for dealing with this issue is
to split it; since the heart of the matter is covered in FUNCTION-TYPE,
we should pursue FUNCTION-TYPE, and deal with the other parts of the
proposal (remove #. from standard read table, etc.) separately.
Please cc: willc on messages regarding FUNCTION-TYPE, as he is not a
member of CL-CLEANUP.
∂22-Sep-87 1347 FAHLMAN@C.CS.CMU.EDU [remailed] Re: APPEND-DOTTED
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:47:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 16:46:39-EDT
Date: Tue, 22 Sep 1987 16:46 EDT
Message-ID: <FAHLMAN.12336723575.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [remailed] Re: APPEND-DOTTED
In-reply-to: Msg of 22 Sep 1987 15:52-EDT from Masinter.pa at Xerox.COM
Larry,
Welcome back.
Would it be possible to mail out a summary of where all the old issues
stand before we start digging in the issues file for new items. I still
don't know what, if anything, was settled in Boston, since I wasn't
there and since the minutes have not appeared.
I gather from some message you sent earlier that the issue of strict vs.
maximally compatible FUNCTION-TYPE was not settled, and that in fact
this issue was further obscured by lots of semi-related questions that
people raised? Were all the other issues disposed of? Were ANY of the
other issues disposed of? Just trying to get a clear picture of where
we stand...
-- Scott
∂22-Sep-87 1434 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 14:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:20:17 PDT
Date: 22 Sep 87 14:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
To: cl-cleanup@Sail.stanford.edu
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870922-142017-12589@Xerox>
I've thought about FUNCTION-TYPE on and off over the summer, as one of
the more important issues for us to revisit. I've changed my mind; I am
now in favor of STRICT-REDEFINITION as long as the proposal that
specifies that it "is an error" to give symbols to functions that expect
functions. ) as long as the restriction is "is an error" rather than
"signals an error".
I think that the proposal has technical (linking, analysis) and
aesthetic (cleaner language semantic) advantages, and that backward
compatibility is well-served by noting that many implementations will
continue to support automatic coercion.
I think we owe X3J13 a new draft of the proposal with fewer (rather than
more) alternatives expressed.
All of the alternatives expressed so far have some flaws. I'm willing to
work on the STRICT-REDEFINITION proposal to correct its problems (e.g.,
deal with *MACROEXPAND-HOOK*, add COERCE to type FUNCTION).
Are there any volunteers to work on any of the other proposals?
∂22-Sep-87 1434 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 14:34:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:22:41 PDT
Date: 22 Sep 87 14:21 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Status
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <870922-142241-12598@Xerox>
I'm working on my status file to update it. Since Scott asked, I'll send this version now and another version, probably tomorrow. I'm only part-way done -- please don't bother to send correction and review for issues after FUNCTION-TYPE in this list.
To summarize: some issues were "passed" at X3J13. Others were discussed. At a meeting of cl-cleanup prior to X3J13, we went over the issues.txt file and attempted to divvy up some of the files.
In some cases, I've indicated a question ???? on whether an item is ready to release. I'd like everyone to reply, either with an accept, don't care, or object on each releasable item.
Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: if you do not reply to this issue,
I will take the action indicated.
In particular, if it says "???? Ready for release with endorsement", I propose to edit the last submitted version of the proposal as sent to CL-CLEANUP to include the statement that the cleanup committee endorses the proposal, and send it on to X3J13.
!
* Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
(Suggestion to add a Related Issues field; LMM proposes instead
just to use References field.)
???? Version 12 modified to suggest naming Related Issues in the References field.
ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Masinter (or other volunteer) to revise, clarify :displaced-to ommitted
same as :displaced-to nil.
Not ready for release.
ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
(p 297) Specify that the fill pointer is ignored for the purposes of deciding whether a given element of a new array resulting from ADJUST-ARRAY
should take its value from the old array contents or from the specified :INITIAL-ELEMENT.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
APPEND-DOTTED (version 1/27 Jul 87)
Sumbitted by KMP.
Need mod to Current Practice
Mention (append () t), clarify NCONC?
Not ready for release.
APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file)
(p 322) At end of second paragraph on *APPLYHOOK*,
clarify that the apply hook function is not used
when special forms are evaluated.
Masinter to submit.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
The summary says Version 2, but I only have version 1 on file.
Does anyone else have a version 2? Or was this wishful thinking?
Not ready for release
{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Postponed pending error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
DEFINITION-FUNCTIONS (not yet submitted)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Masinter to submit.
{ DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have
the same name. If structure A includes structure B, then no additional
slot of A may have the same name as any slot of B.
Await object proposal.
{ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) The default value in a defstruct slot is not evaluated unless it
is needed in the creation of a particular structure instance. If it is
never needed, there can be no type-mismatch error, even if the type of the
slot is specified, and no warning should be issued.
Await object proposal.
* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
(Documentation string is not evaluated.)
Submitted, no replies
???? Ready for release with endorsement?
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13/Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
Clarify that if DISASSEMBLE is given a symbol whose function definition is interpreted, that definition is indeed compiled and then disassembled, but the resulting compiled definition does not replace the interpreted one as the symbol's function definition.
Need volunteer to submit.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Postpone pending FUNCTION-TYPE resolution &
handle remainders.
EXPORT-COORDINATION (from Carnese, no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Not yet formally submitted.
???? Drop this issue?
{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. "
Awaiting error proposal.
FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument."
Need volunteer to write up.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?
FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except as specifically stated"
Need volunteer to write up.
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
<<< status and notes after this point are incomplete and possibly inaccurate >>>
FUNCTION-SPECS (mail 17 Jul)
GET-SETF-METHOD-ENVIRONMENT (mail 23-Jul)
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions?
Mail 6-Jul
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
(Was not released).
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
Mail 30 Jul
LISP-SYMBOL-REDEFINITION
Mail 22 Aug
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
Deferred to compiler committee?
Mail 23-Jul
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
Masinter will extract from environment-arguments
OPEN-KEYWORDS (mail 27-JUL)
* PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Needs revision to clarify "file" = "opened with open"
(there are some non-file devices which have pathnames)
Mail 11-Jun
PATHNAME-SUBDIRECTORY-LIST (mail 23-Jul)
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
Moon will revise, extend language, clarify
which functions are affected, etc.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
Pitman will revise & resubmit.
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
Rees & Moon will revise & resubmit. Rees says he won't.
David? Mail 4 Aug.
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
Tabled indefinitely.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
Table indefinitely.
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
Pitman will revise & resubmit.
SETF-EVALUATION-ORDER (not yet submitted)
(Clarify SETF order) (subsume PUSH-EVALUATION-ORDER,
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
Need volunteer to submit. (SETF-VARIABLE? submitted by Moon. Expand?)
SETF-METHOD-FOR-SYMBOLS
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
Pitman will revise & resubmit.
SHADOW-ALREADY-PRESENT (???)
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
Forward to Linden for character proposal?
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
Pitman will revise & resubmit.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
Send to macro committee?
STANDARD-INPUT-INITIAL-BINDING
(P 328) Remove the requirement that *STANDARD-INPUT*, etc., must be initially bound to synonym streams to *TERMINAL-IO*; demote this to the level of an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX redirection to win.
SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
Masinter will revise & resubmit.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
Gabriel will revise & resubmit.
∂22-Sep-87 1434 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 14:34:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:22:41 PDT
Date: 22 Sep 87 14:21 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Status
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <870922-142241-12598@Xerox>
I'm working on my status file to update it. Since Scott asked, I'll send this version now and another version, probably tomorrow. I'm only part-way done -- please don't bother to send correction and review for issues after FUNCTION-TYPE in this list.
To summarize: some issues were "passed" at X3J13. Others were discussed. At a meeting of cl-cleanup prior to X3J13, we went over the issues.txt file and attempted to divvy up some of the files.
In some cases, I've indicated a question ???? on whether an item is ready to release. I'd like everyone to reply, either with an accept, don't care, or object on each releasable item.
Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: if you do not reply to this issue,
I will take the action indicated.
In particular, if it says "???? Ready for release with endorsement", I propose to edit the last submitted version of the proposal as sent to CL-CLEANUP to include the statement that the cleanup committee endorses the proposal, and send it on to X3J13.
!
* Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
(Suggestion to add a Related Issues field; LMM proposes instead
just to use References field.)
???? Version 12 modified to suggest naming Related Issues in the References field.
ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Masinter (or other volunteer) to revise, clarify :displaced-to ommitted
same as :displaced-to nil.
Not ready for release.
ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
(p 297) Specify that the fill pointer is ignored for the purposes of deciding whether a given element of a new array resulting from ADJUST-ARRAY
should take its value from the old array contents or from the specified :INITIAL-ELEMENT.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
APPEND-DOTTED (version 1/27 Jul 87)
Sumbitted by KMP.
Need mod to Current Practice
Mention (append () t), clarify NCONC?
Not ready for release.
APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file)
(p 322) At end of second paragraph on *APPLYHOOK*,
clarify that the apply hook function is not used
when special forms are evaluated.
Masinter to submit.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
The summary says Version 2, but I only have version 1 on file.
Does anyone else have a version 2? Or was this wishful thinking?
Not ready for release
{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Postponed pending error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
DEFINITION-FUNCTIONS (not yet submitted)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Masinter to submit.
{ DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have
the same name. If structure A includes structure B, then no additional
slot of A may have the same name as any slot of B.
Await object proposal.
{ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) The default value in a defstruct slot is not evaluated unless it
is needed in the creation of a particular structure instance. If it is
never needed, there can be no type-mismatch error, even if the type of the
slot is specified, and no warning should be issued.
Await object proposal.
* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
(Documentation string is not evaluated.)
Submitted, no replies
???? Ready for release with endorsement?
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13/Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
Clarify that if DISASSEMBLE is given a symbol whose function definition is interpreted, that definition is indeed compiled and then disassembled, but the resulting compiled definition does not replace the interpreted one as the symbol's function definition.
Need volunteer to submit.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Postpone pending FUNCTION-TYPE resolution &
handle remainders.
EXPORT-COORDINATION (from Carnese, no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Not yet formally submitted.
???? Drop this issue?
{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. "
Awaiting error proposal.
FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument."
Need volunteer to write up.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?
FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except as specifically stated"
Need volunteer to write up.
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
<<< status and notes after this point are incomplete and possibly inaccurate >>>
FUNCTION-SPECS (mail 17 Jul)
GET-SETF-METHOD-ENVIRONMENT (mail 23-Jul)
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions?
Mail 6-Jul
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
(Was not released).
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
Mail 30 Jul
LISP-SYMBOL-REDEFINITION
Mail 22 Aug
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
Deferred to compiler committee?
Mail 23-Jul
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
Masinter will extract from environment-arguments
OPEN-KEYWORDS (mail 27-JUL)
* PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Needs revision to clarify "file" = "opened with open"
(there are some non-file devices which have pathnames)
Mail 11-Jun
PATHNAME-SUBDIRECTORY-LIST (mail 23-Jul)
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
Moon will revise, extend language, clarify
which functions are affected, etc.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
Pitman will revise & resubmit.
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
Rees & Moon will revise & resubmit. Rees says he won't.
David? Mail 4 Aug.
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
Tabled indefinitely.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
Table indefinitely.
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
Pitman will revise & resubmit.
SETF-EVALUATION-ORDER (not yet submitted)
(Clarify SETF order) (subsume PUSH-EVALUATION-ORDER,
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
Need volunteer to submit. (SETF-VARIABLE? submitted by Moon. Expand?)
SETF-METHOD-FOR-SYMBOLS
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
Pitman will revise & resubmit.
SHADOW-ALREADY-PRESENT (???)
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
Forward to Linden for character proposal?
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
Pitman will revise & resubmit.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
Send to macro committee?
STANDARD-INPUT-INITIAL-BINDING
(P 328) Remove the requirement that *STANDARD-INPUT*, etc., must be initially bound to synonym streams to *TERMINAL-IO*; demote this to the level of an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX redirection to win.
SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
Masinter will revise & resubmit.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
Gabriel will revise & resubmit.
∂22-Sep-87 1513 Masinter.pa@Xerox.COM status: remaining ISSUES.TXT file
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 15:13:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 15:13:59 PDT
Date: 22 Sep 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: status: remaining ISSUES.TXT file
To: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <870922-151359-12701@Xerox>
For the record, this is the remainder of the issues file that Scott worked on -- was it 1.5 years ago -- that I don't believe have made it into proposals yet. This is my "working copy":
This file contains a list of issues and proposals for the X3J13 cleanup
committee to consider. It is broken into several sections, divided by a
line of ='s.
* Editorial changes: items that merely clarify what must currently be
decyphered out of CLtL; not changes to Common Lisp but to the language
describing it.
* Simple clarifications: items that are unclear, contradictory, or
underspecified in CLtL. In these cases, the proper fix seems obvious.
* Complex clarifications: these may require a bit more discussion.
* Simple changes: proposed small changes that may or may not be
desirable.
* Complex changes: these are more complex or fundamental changes that
will probably require extensive discussion. Some of them require the
development of a specific proposal.
* Proposed additions: these are additions or compatible extensions that
may or may not be worth adding to the language. Some of them require
the development of specific proposals. In general, these are less
urgent than the clarifications and proposed changes.
* Issues to pass along to the compiler committee.
The clarifications on Steele's list of Jan, 1986, are included here
except for those that have been withdrawn or extensively modified by
later discussion. The initial judgements about which issues are simple
and which are complex were made by Scott Fahlman, who has frequently
been wrong about such things in the past.
This file does not currently reflect proposals made after the August
1986 Lisp conference. The formal proposals discussed just before the
Lisp conference are included here, more or less as place-holders. I
have not yet dug through the relevant mail to find all of the options
and amendments that were proposed in the course of discussion.
The plan is to have the "cleanup" subcommittee of X3J13 turn these
issues into a series of proposals that will be sent to the Clisp mailing
list for comment, then to the full X3J13 committee, which will consider
whether to include these changes in the forthcoming Common Lisp
standard.
Editorial changes:
---------------------------------------------------------------------------
(p ???)
Modify the general rule about operating only on active elements of arrays to exclude ADJUST-ARRAY, SETF of AREF, ROW-MAJOR-AREF, and SETF of ROW-MAJOR-AREF.
---------------------------------------------------------------------------
p ???
Modify the description of APROPOS to replace the words ``available in'' to
``accessible in,'' and specify that APROPOS on a given package finds the
same symbols that DO-SYMBOLS would.
---------------------------------------------------------------------------
"Throughout: Adopt the term "special operator" for the symbol that
introduces a special form, leaving "special form" to refer to the whole
form. Note that the name SPECIAL-FORM-P is not quite accurate, since it acts on the symbols that introduce forms rather than the forms themselves."
p 274: Clarify by example that NSUBST-IF-NOT is perhaps non-intuitive:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (nsubst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
---------------------------------------------------------------------------
Page 113:
Clarify that the bindings created by FLET and LABELS have lexical scope
and indefinite extent. The functions themselves have indefinite extent.
---------------------------------------------------------------------------
Page 426:
Make explicit that when a compiled file is loaded, symbols naming
lexical variables in the code may or may not be created. This is left up
to the implementation.
===========================================================================
SIMPLE CLARIFICATIONS:
---------------------------------------------------------------------------
Page 379:
Specify that PEEK-CHAR operations on echo streams should not echo. The
echo occurs when the character is actually read. (We may have to add "on
systems which can manage this", since there may be some that cannot.)
---------------------------------------------------------------------------
Page 404:
Specify that the ~< ... ~> directives to FORMAT divide the whitespace
evenly into the gaps between the units of text. Any remaining quanta of
whitespace are distributed into gaps from left to right, not placed
randomly.
---------------------------------------------------------------------------
Page 140:
Clarify that in an UNWIND-PROTECT, the cleanup forms are executed in the
dynamic environment of the UNWIND-PROTECT itself.
---------------------------------------------------------------------------
Page 51:
Clarify that coerce MAY NOT copy the argument if it is already of the
correct type. (At present, the manual is inconsistent on whether a copy
is allowed.)
---------------------------------------------------------------------------
Page 426:
Clarify what the :VERBOSE and :PRINT options to LOAD do, or at least what
their intent is.
One proposal, by SEF:
1. Load with no switches should not print anything on standard-output.
2. The :verbose switch is intended to print some per-file information
and an indication when the loading is done, but not something for every
form that is loaded.
3. The :print switch is intended to cause the read/eval/print loop's
output to be printed, or if the file is compiled, something for each
form that is loaded.
4. These are only guidelines covering the intent of how these switches
are to be used. Implementations are free to indicate this kind of
information in other ways if that makes sense in their environment.
---------------------------------------------------------------------------
Page 67:
Clarify that argument-list init-forms are NOT lexically within the block
established by the Defun of which they are a part. (Most implementations
have done it this way.)
---------------------------------------------------------------------------
Page 422:
Clarify that WITH-OPEN-FILE returns the value(s) of the last form in the
body.
---------------------------------------------------------------------------
Page 200, 215:
Clarification: Division by 0 should be documented to be an error. It
doesn't seem to be at present.
[For flonums, maybe allow IEEE-type infinities here. Wait for error
proposal before discussing whether error must be signalled and how.]
---------------------------------------------------------------------------
Page 50, 307:
Clarification: It is an error to redefine an built-in type via DEFSTRUCT or
DEFTYPE. [Coordinate with object proposal.]
---------------------------------------------------------------------------
Page 316:
Clarify that if a defstruct specifies a BOA constructor, the default
keyword-style constructor is not also defined. (OR clarify that it is.)
---------------------------------------------------------------------------
Page 280:
Clarify that the :KEY argument to ASSOC is applied to the car of each list,
not the whole pair.
---------------------------------------------------------------------------
Page 104:
In the description of the second value of a setf method:
A list of *value forms* (subforms of the given form) to whose values
the temporary values are to be bound.
preface the parentheical remark with "often" or "usually". It is not
always true, as in the following example:
(DEFMACRO ELT-IF (SEQ PRED IND1 IND2)
`(ELT ,SEQ (IF ,PRED ,IND1 ,IND2)))
The setf method of (ELT2 S P A B) is defined to be the same as that of
(ELT S (IF P A B)). There is no way to express the setf method of this
form in terms of the values of subforms of (ELT2 S P A B), since A and
B are not always evaluated. In the implementations I have checked, the
setf method of (ELT2 S P A B) has value forms S and (IF P A B).
The current statement is also harmful if read as a prescription for
DEFINE-SETF-METHOD, since it is then impossible to define SETF methods
for forms that do not always evaluate all of their arguments.
---------------------------------------------------------------------------
Page 130:
Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.
Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY. (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)
===========================================================================
COMPLEX CLARIFICATIONS:
---------------------------------------------------------------------------
Page ???:
It is not specified what happens when the same (EQL) variable appears more
than once in a lambda-list or binding form (LET, LET*, etc.). This was
discussed at some length in June/July 1986. Possible options:
1. It is an error.
2. Latest (rightmost) binding governs in all forms.
3. It is an error in parallel-binding forms and lambdas, but rightmost
governs in serial-binding forms such as LET*.
[Related issue: special dispensation to allow multiple uses of ignored
variables? Bring back IGNORE as a universally-ignored variable?]
---------------------------------------------------------------------------
Page 68:
(merge with LISP-SYMBOL-REDEFINITION)
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.
Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable. It is an error to execute such
code.
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[Needed for reloading compiled code files.]
---------------------------------------------------------------------------
Page 413, 424:
The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified. The requirement that PROBE-FILE never return
NIL on an open file is clearly broken. Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL. Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different. There also needs to be some discussion of the
meaning of operations on closed streams. The manual never says which
operations may be done on closed streams, let alone what the
operations do.
---------------------------------------------------------------------------
Page ???:
Define carefully which returned values may be shared structure. These
must not be destructively modified (or should be copied if you want to
be safe). Symbol name-strings, rest-arg lists...
---------------------------------------------------------------------------
Page 93:
Clarify that MACROLET shadows any setf function for the associated macro:
(DEFUN LOSER (X)
(CAR X)
(DEFUN SET-LOSER (X Y)
(SETF (CAR X) Y))
(DEFSETF LOSER SET-LOSER)
(DEFUN LOSSAGE (X Y)
(MACROLET ((LOSER (X)
`(SYMBOL-VALUE ,X)))
(SETF (LOSER X) Y)))
LOSSAGE calls SET, not SET-LOSER.
---------------------------------------------------------------------------
Page 113:
Clarify that FLET shadows DEFMACRO.
---------------------------------------------------------------------------
Page 321:
Modify EVAL to have an optional environment argument.
[I think this is unwise. -- SEF]
---------------------------------------------------------------------------
Page 440:
Specify explicitly that one may trace macros as well as functions.
[Is this feasible in all implementations? CF CLOS trace proposal]
---------------------------------------------------------------------------
Page 80:
Clarify what EQUAL and EQUALP do on structures. Proposal: If the
structures are of the same type, both EQUAL and EQUALP do component-wise
comparison.
---------------------------------------------------------------------------
Page 112:
Clarify Compiler-Let or flush it. [SEF: Flush it.]
---------------------------------------------------------------------------
Page 389:
Need a portable way to print a #\SPACE as " ". (FORMAT NIL "~C"
#\Space) may or may not do this. Same with PRINC. For Standard
characters, it is safe to be more specific about how things are printed.
---------------------------------------------------------------------------
Page 160:
Either specify that IGNOREd arguments do not generate a warning if you
use them after all, or add a new declaration IGNORABLE.
[Stupid issue, discussed to death earlier.]
---------------------------------------------------------------------------
Page 295:
Proposed clarifications regarding fill pointers:
If no fill pointer is specified to Make-Array, the implementaiton is
not required to supply a fill-pointer, but may do so.
If a destructive sequence function such as DELETE is passed an array
with a fill pointer, it may change the active size of the array by
manipulating the fill pointer; it is not required that the underlying
array's ARRAY-DIMENSION be altered.
If ADJUST-ARRAY is called on a vector with a fill pointer, but is not
given a :FILL-POINTER argument, the fill-pointer is retained and is
reset to the new length of the vector.
---------------------------------------------------------------------------
Page 249 and elsewhere:
What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.? Specify that it is an error, or require it to work?
[ There's a real split on this issue. To some people, circular lists
are a clever hack and this obviously should work. To others, they are
an evil that should not be encouraged. SEF and GLS have argued in favor
of treating this as an error. ]
---------------------------------------------------------------------------
Page 307:
Does COPY-FOO (where foo is a structure) work on subtypes that include
FOO? Does COPY-PERSON work on ASTRONAUT?
[Subsumed by object proposal? Gregor suggests: COPY-xxx as defined by a
defstruct returns a structure of that defstruct's type. COPY returns a
structure of the same type as its argument.]
---------------------------------------------------------------------------
Page 152:
Clarify (figure out) how MACROLET and *MACROEXPAND-HOOK* interact.
---------------------------------------------------------------------------
Page 447:
Clarify by example what sort of thing goes into
LISP-IMPLEMENTATION-TYPE, etc.
---------------------------------------------------------------------------
Page ???:
Clarify the ways in which an implementation may extend pure Common Lisp:
Extra keywords to specified functions? To all functions? Extra return
values? Functions working on otherwise illegal types? Require a compiler
mode that catches non-Common stuff? Should we document certain specific
functions (e.g. COMPILE) as allowing implementation-specific keyword
extensions. (cf IF-BODY discussion)
---------------------------------------------------------------------------
Chapter 23:
Pathnames and the file system interface require much clarification and
probably some changes. A comprehensive proposal is needed here.
The Symbolics solution might work for us. If we can't fix this up, we
should consider dumping the whole thing and going with something very
simple and minimal, such as a raw string in system-specific format to
designate a file.
---------------------------------------------------------------------------
Page 145:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
---------------------------------------------------------------------------
Page 60:
Decide whether an &rest arg is required to be a freshly-consed list or
whether it may be part of a pre-existing list passed in by APPLY.
---------------------------------------------------------------------------
Page 162:
Decide what the behavior of (THE (VALUES ...) form) should be. Does it
specify exactly how many values should be returned, or a lower limit, or
what?
One proposal: in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
[Discussed June/July 1986.]
===========================================================================
SIMPLE CHANGES:
---------------------------------------------------------------------------
Page 239:
Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.
[May be subsumed under a wholesale redesign of character objects,
eliminating the BIT and FONT attributes. Character committee??]
---------------------------------------------------------------------------
Page 202:
Define (LCM) to return 1 (the manual is incorrect in claiming that the
result should be infinity).
---------------------------------------------------------------------------
Page 377:
Extend READ-DELIMITED-LIST by adding one more optional argument,
dot-permitted-p, defaulting to nil, that if true allows the delimited list
to contain dot notation, and if false forbids dot notation.
---------------------------------------------------------------------------
Page 323:
Eliminate the ENV argument to APPLYHOOK, which is useless.
---------------------------------------------------------------------------
Page 418:
Flush :DIRECTION :PROBE as an allowable argument to OPEN.
---------------------------------------------------------------------------
Page 171 ff:
All functions that take a package as an argument, except those
named PACKAGE-xxx, will also take a string or symbol and do an implicit
find-package. This gives users maximum flexibility and minimum confusion.
---------------------------------------------------------------------------
Page 316:
BOA constructors take keywords, with the obvious semantics.
---------------------------------------------------------------------------
Page 251:
(reduce #'+ list-of-objects :KEY #'object-quantity) would apply the
function OBJECT-QUANTITY to each element of the list-of-objects before
reducing it with +.
---------------------------------------------------------------------------
Page 327:
Functions that require a string, pathname, stream, or symbol
should not accept a symbol. NIL is confusing, and some implementations
use symbols for certain streams. [Proposal by Moon]
---------------------------------------------------------------------------
Page 305:
Require that structures (created without the :TYPE specifier) are
disjoint from the other built-in types such as vector? They already
must be distinguishable from plain old vectors.
---------------------------------------------------------------------------
Page ???:
Forbid implementations to produce unsolicited output to
*standard-ouput*. Output to *error-ouput* is always OK.
---------------------------------------------------------------------------
Page 444:
In the description of Decoded Time format, the Time-zone component is
required to be an integer which is the number of hours west of GMT.
(The latest term is Coordinated Universal Time, or UTC, by the way).
Since time zones are not always an integral number of hours west of GMT,
this should be changed to either (a) a non-complex, non-negative number
which is the number of hours west of GMT, or (b) an integer which is the
number of {minutes, seconds} west of GMT.
===========================================================================
COMPLEX CHANGES:
---------------------------------------------------------------------------
Page 210:
Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations. (Paul Penfield intends to recommend the same change to
the APL community.)
[Steele should produce a specific proposal without forwarding pointers.]
---------------------------------------------------------------------------
Page 181:
There must be a package with only the official Common Lisp symbols,
either named LISP or COMMON-LISP. Work out where
implementation-specific extensions go. Several proposals exist.
---------------------------------------------------------------------------
Page 80:
EQUAL should descend into arrays, if they are the same type and
dimensionality, comparing leaves by EQL.
[SEF: I was partly to blame for the decision not to do this. I now
believe that we blew it here, and should consider un-blowing it. The
change will break some code, but the community might accept it anyway.]
---------------------------------------------------------------------------
Page 26, 42:
Alter the LIST type-specifier to distinguish proper lists from others and
to specify the element-type of the list.
---------------------------------------------------------------------------
Page 93:
Flush MACROLET, thereby doing away with environment arguments and related
confusion.
[This has been proposed N times and rejected each time on the grounds that
MACROLET is not *totally* useless, but I still think that this is the right
thing to do. -- SEF]
---------------------------------------------------------------------------
Page 154:
Eliminate the provision that a macro at the start of a body may expand
into a declaration.
[KMP, who was one of the more vocal proponents of this feature, has
now suggested that we consider flushing it. It requires some confusing
environment hackery to do this right.]
---------------------------------------------------------------------------
Page 322:
Flush *applyhook* and *evalhook* and related hackery. Does anyone use
this (correctly) for anything other than implementing steppers? If not,
it may be preferable to forget about portable stepper hooks and make
stepping an implementaiton-dependent facility like DEBUG. These hooks
cause an awful lot of confusion and anxiety for users and implementors.
---------------------------------------------------------------------------
Page 153:
Proposed alterations to SPECIAL declaration and possible addition of
UNSPECIAL (see Common Lisp mail around July 1986 including proposal by
Pavel). One or more coherent proposals have to be constructed for
consideration.
---------------------------------------------------------------------------
Page 58:
Turn the warning that standard macros should not expand into
non-standard special forms into a requirement. Makes life easier for
code-walkers.
[Can all implemenations live with this?]
---------------------------------------------------------------------------
Page ???:
Three related, controversial proposals on case-sensitivity for symbols.
1) Add a switch that would tell read and friends to suppress case
conversion, along with a note indicating that portable code assumes this
switch to be OFF.
[SEF: This is the proposal dear to the unix people. I still think that
it is asking for trouble to put this in. Some code will assume this
switch despite the warning, some won't, and the two kinds of code will
not mix.]
2) Alternatively, think again about making the language case-preserving,
but with INTERN ignoring case completely. This means that there is *NO*
way to create two symbols, one named "FOO" and the other named "foo",
but now that we have strings this may not be necessary.
[SEF: I now believe that this is what we should have done, but it is
probably too radical a change to consider at this point.]
3) Add a property of read tables which tell whether READ under the read table preserves case. READ-CHAR is not affected.
[LMM: This is the way Xerox Lisp handles it, and it works very well. It puts case sensitivity where it belongs, as part of the read-table description.]
---------------------------------------------------------------------------
Page 171:
Even if we keep the status quo for symbols, we may want to reconsider
the rules on case-sensitivity for package names. Need a specific
proposal and analysis of transition strategy.
[LMM: this is unnecessary, I think.]
---------------------------------------------------------------------------
Page 382:
How to communicate the current depth in printing when there are
user-defined print functions? Guy said that what had in mind was that
the user would bind *print-level* according to the depth arg supplied to
the print function, but there were several problems with this. Most of
the tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer. Others objected that
nobody wants to use WRITE directly, so that isn't a real fix.
---------------------------------------------------------------------------
Chapter 13:
[Not in cleanup committee....]
We need a comprehensive proposal for handling extended characters
(16-bit char-code, plus possibly other fields) and strings of extended
characters. The Japanese are developing a Kanji standard. Maybe we
can just adopt this; certainly we must coordinate with it.
At the same time, consider whether to retain the char-bit and char-font
fileds in present form. Since an implementaiton may omit these fields,
this should not break truly portable code.
===========================================================================
PROPOSED ADDITIONS:
---------------------------------------------------------------------------
Page ???
Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time. (Discussed by not good results).
---------------------------------------------------------------------------
Page 226:
Add SIGNED-LDB. Like LDB but sign-extends the extracted byte.
---------------------------------------------------------------------------
Page 283:
Add functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.
[ Which, if any, are SETF-able? What does hash-table-test return, the
function object for the test function? ]
---------------------------------------------------------------------------
Page 439:
Add COMPILEDP. This takes a function and returns non-NIL if it is a
compiled function, and NIL if it is not. If the function is a symbol
whose compiled-function definition was installed by the COMPILE
function, then the non-NIL value returned is the interpreted definition
that was compiled.
---------------------------------------------------------------------------
Page 439:
Add UNCOMPILE. This takes a symbol and restores the previous
interpreted definition of that symbol if that symbol previously had an
interpreted definition and was then given to COMPILE; otherwise no
action is taken.
---------------------------------------------------------------------------
Page 447:
Add USER-NAME. This returns a string identifying the user of the Common
Lisp system, or NIL if that cannot be determined.
---------------------------------------------------------------------------
Page 327:
Add *DISCARD-OUTPUT-STREAM* (alias, the bit bucket).
[Make this a constant so that it can be optimized? You should never want
to rebind this to another value.]
---------------------------------------------------------------------------
Page 117:
Add (CASE-WITH-TEST test item ...clauses...).
---------------------------------------------------------------------------
Page 51:
Extension: Let COERCE coerce symbols to strings. NIL is treated as the
empty sequence, not a symbol. Also let COERCE turn string-chars into
strings of length 1.
---------------------------------------------------------------------------
Page ???:
Add TRUE and FALSE, functions that take any number of args, ignore them,
and return T and NIL respectively.
Someplace:
---------------------------------------------------------------------------
Page 95, 267:
Add SETF of NTHCDR.
---------------------------------------------------------------------------
Page 158:
Add a TYPE-RESTRICT declaration. (TYPE-RESTRICT type1 type2), where
type2 is a subtype of type1, says that within the scope of the
declaration if the compiler can prove a value is of type1, it is
allowed to assume that it is of type2. This gets rid of a lot of
multiple-THE forms when you want maximally tense code.
---------------------------------------------------------------------------
Page 73:
Fill out the set of mumble-P type predicates. Currently we have some
and not others.
---------------------------------------------------------------------------
Page ???:
We need a set of "undoing" functions, so that interactive errors and
failed experiments can be recovered from without starting over.
See comprehensive proposal by Eric Benson.
[SEF: A generic "undo" facility, like SETF, has been opposed on various
occasions, but is a bad idea because users will expect too much of it,
and complain when it doesn't undo everything.]
[cf DEFINITION-FUNCTIONS, in prep]
---------------------------------------------------------------------------
Page 336:
Add (syntax-type <character>), which returns one of the following:
:illegal, :whitespace, :constituent, :single-escape, :multiple-escape,
:terminating-macro, :non-terminating-macro.
[Make this setf-able? If so, what do we do about macro characters that
have no definitions?]
---------------------------------------------------------------------------
Page 283:
Add EQUALP hash-tables? Case-insensitive hash-tables for strings? Let
the user provide his own test (with associated hashing function)? [Need
a coherent proposal.]
---------------------------------------------------------------------------
Page ???:
Have a function COPY that can copy any single object. For a CONS cell
it would copy just that CONS. Whether (EQ X (COPY X)) for X a character
or number is implementation-dependent.
[Proposal in archives by Morrison, needs some tuning.]
---------------------------------------------------------------------------
Page 171:
We need a way to say "use all the symbols from package FOO except for X,
Y, ..." Shadowing is no good, since you might want to inherit X from
somewhere else. Also, do we want a make-package that says ALL symbols
get exported?
---------------------------------------------------------------------------
Page ???:
Fahlman's proposal for &more arguments, similar to &rest but leaves the
arguments on the stack LEXPR-style. Removes one of the worst inherent
efficiency problems in Common Lisp.
---------------------------------------------------------------------------
Page 438:
Review and develop a general philosophy on the handling of semi-standard
system interface functions such as GC, BYE, ED, SAVE-SYSTEM, etc. Then
see what we want to add (or remove).
---------------------------------------------------------------------------
Page ???:
Consider FUNCTION-PARAMETERS and related proposals that were discussed
extensively in June/July 1986.
---------------------------------------------------------------------------
Page ???:
Consider PARSE-BODY and extended syntax for &BODY, as discussed in
June/July 1986.
[Note, if we flush MACROLET or eliminate macro-expansion into
declarations, this extension becomes less critical, though it may still
be useful.]
---------------------------------------------------------------------------
Page 154:
Permit declarations before the body of a LABELS, FLET, or MACROLET.
===========================================================================
For the compiler committee:
---------------------------------------------------------------------------
A lot of compiler/eval-when issues need to be settled. Among the
issues: Define clearly how REQUIRE interacts with the compiler. Are
DEFSETF-generated available in the compiler environment by default?
---------------------------------------------------------------------------
Package interactions with COMPILE and LOAD need to be worked out better.
Restrict IN-PACKAGE, IMPORT, and firends to the start of files only?
Add a new declarative form to handle this? Some favor legitimzing -*-
forms, but this is unacceptable to many.
---------------------------------------------------------------------------
Related issue: Add INCLUDE, or some other way to stuff multiple source
files into one binary? (Package hackery makes this complicated.)
---------------------------------------------------------------------------
Related issue: There should be some discussion of the semantics of
compilation on literal constants (things appearing in quoted structure
in code). To what degree is sharing and non-sharing preserved? Many
implementations both introduce and remove sharing. Probably most don't
dump circular structures.
---------------------------------------------------------------------------
What things can a compiler optimize by inline expansion, tail-recursion
elimination, etc.? What things must be handled correctly if the user
redefines a built-in function (or specializes it using the object
facility)?
Proto-proposal: All built-in functions may be optimized inline
(and therefore do not respond to later modifcation) unless this is
inhibited with a NOTINLINE declaration. Maybe create a list of
functions such as PRINT that are not open-coded by default. Also,
within a DEFUN, a recursive call to the function being defined may be
optimizied into a jump, unless this is inhibited by NOTINLINE. (Maybe
think up a better term than NOTINLINE.)
---------------------------------------------------------------------------
NEW:
Declare *print-circle* means to print out shared structure too. Alternative: add another variable *print-shared*. Alternative: add another value to *print-circle* (nil :none t :unspecified :circular :shared).
∂22-Sep-87 1929 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 87 19:28:59 PDT
Date: Tue 22 Sep 87 19:27:09-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870922-130335-12464@Xerox>
Message-ID: <12336785573.41.CARNESE@SPAR-20.ARPA>
My fault for dropping the ball on this discussion.
The two principal objections that have been made are:
1) [RAM] Some uses of the proposed construct would not have
well-defined behavior under the current definition of Common Lisp.
2) [JonL] Readability concerns argue that package structuring
should occur in a standard place. This might be a special non-code file,
such as Mesa's module definitions, or at the start of each code file.
The response to 1) was:
3) The new construct simply maps to existing ones. Thus, if you
can define the correct behavior for existing constructs, the new one will
behave properly as well.
Although not explicitly stated, the response to 3) from Rob seems to be:
4) Allowing package-related operations to occur anywhere in a file
is itself problematic and perhaps will be removed as part of a solution.
Since the proposed constructs will result in such operations, the constructs
should not be added to the language.
Here's where I pick up the ball again. Suppose the language is changed so
that package operations are determinable without evaluating forms. The
obvious ways to do this are compatible with the new construct.
5a) The langauge could be changed so that a set of special forms
evaluated at read time would perform the package operations. This might
involve changing existing functions (e.g., in-package and export) to have
read-time semantics, or introducing new functions which have such
semantics. In either case, the proposed constructs would macro-expand into
a read-time export followed by the standard definition.
5b) The langauge could be changed to require a standard header
which would not consist of forms to be evaluated, i.e., the file attribute
list approach. Then the standard behavior for the proposed constructs
while reading a file would be to verify that the symbol being defined has
in fact been exported. Of course it should also be possible to have the
constructs export the symbol rather than signalling an error, based on the
value of a global variable.
Under either of these approaches, the use of the proposed constructs can
allow the programming environment to help the user in the construction and
maintenance of export lists. Editor commands such as "create export
declarations from exports of package", "compare export declarations with
current exports for package", and "undefun and unexport symbol" could be
defined. Their availability would mean that the tedious task of keeping
the export declarations up to date could be largely automated.
The proposals involved objection 2) are similar to those described in 5b),
so the same line of reasoning applies.
-------
∂26-Sep-87 1740 Masinter.pa@Xerox.COM reply to yuasa message
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 87 17:40:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 87 17:41:03 PDT
Date: 26 Sep 87 17:40 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: reply to yuasa message
Message-ID: <870926-174103-17910@Xerox>
Feeling less presumptious than usual, I thought it would be
presumptuous of me to send this, which sounds like it speaks for
cl-cleanup, without checking it out with you. Opinions?
Subject: Re: Japanese Activities toward Lisp Standardization
In-reply-to:
yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay:CSNet:Xerox's message of
24 Sep 87 03:55
To: yuasa%kurims.kurims.kyoto-u.junet@utokyo-relay.cs.net
In the United States, the X3J13 committee of ANSI is progressing toward
establishing a standard for Lisp. As with TG/A, X3J13 has agreed that
Common Lisp is a good starting point for technical discussions. We have
also been discussing various technical deficiencies of Common Lisp and
proposals for their correction.
The Lisp community as a whole can be best served if there are not too
many standards. We would like to invite a member TG/A to participate in
the discussions of the "cleanup" working group of X3J13, and to bring
forward those technical deficiencies that are of most serious concern to
TG/A. Fortunately, almost all of our work goes on using electronic mail.
We would welcome active participation, argumentation, proposals and
criticisms.
∂26-Sep-87 2000 gls@Think.COM reply to yuasa message
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 87 20:00:14 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Sat, 26 Sep 87 23:00:24 EDT
Received: by kali.think.com; Sat, 26 Sep 87 23:00:41 EDT
Date: Sat, 26 Sep 87 23:00:41 EDT
From: gls@Think.COM
Message-Id: <8709270300.AA02152@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 26 Sep 87 17:40 PDT <870926-174103-17910@Xerox>
Subject: reply to yuasa message
Looks okay to me.
--Guy
∂26-Sep-87 2030 FAHLMAN@C.CS.CMU.EDU reply to yuasa message
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Sep 87 20:30:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Sep 87 23:31:06-EDT
Date: Sat, 26 Sep 1987 23:31 EDT
Message-ID: <FAHLMAN.12337845783.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: reply to yuasa message
In-reply-to: Msg of 26 Sep 1987 20:40-EDT from Masinter.pa at Xerox.COM
Looks OK to me, too.
∂28-Sep-87 0910 Moon@STONY-BROOK.SCRC.Symbolics.COM reply to yuasa message
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Sep 87 09:09:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 242883; Mon 28-Sep-87 12:10:47 EDT
Date: Mon, 28 Sep 87 12:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: reply to yuasa message
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870926-174103-17910@Xerox>
Message-ID: <870928121053.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I have no problems with this.
∂08-Oct-87 1655 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 16:55:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 87 16:17:35 PDT
Date: 8 Oct 87 16:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 4)
TO: CL-Cleanup@sail.stanford.edu
CC: MASINTER.pa@Xerox.COM
Message-ID: <871008-161735-1333@Xerox>
This issue passed conditionally last meeting, pending a change in the
wording to not restrict streams with pathnames to "files", since some
users model a "device" as something that isn't a "file". I rewrote the
description and edited the language of other parts of the proposal.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a
pathname, but many sources or sinks of data that streams might be
connected to have no pathnames associated with them; for example,
streams created with make-two-way-stream or open-string-stream. There is
no reasonable way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-ONLY:
Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN, WITH-OPEN-FILE or the like. For
example, it is an error to attempt to obtain a pathname from a
two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost: None.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂09-Oct-87 0927 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 87 09:27:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 252443; Fri 9-Oct-87 12:25:07 EDT
Date: Fri, 9 Oct 87 12:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <871008-161735-1333@Xerox>
Message-ID: <871009122453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This looks okay to me. There is one typographical error. In
Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN, WITH-OPEN-FILE or the like.
|
the word "the" should be removed or the phrase should be changed
to "the OPEN function".
∂09-Oct-87 0927 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 87 09:27:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 252444; Fri 9-Oct-87 12:25:58 EDT
Date: Fri, 9 Oct 87 12:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <871008-161735-1333@Xerox>
Supersedes: <871009122453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Forgot about synonym streams.
Message-ID: <871009122541.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This looks okay to me. There is one typographical error. In
Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN, WITH-OPEN-FILE or the like.
|
the word "the" should be removed or the phrase should be changed
to "the OPEN function".
Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?
∂09-Oct-87 1408 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 14:07:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:07:23 PDT
Date: 9 Oct 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 9 Oct 87 12:25 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871009-140723-1578@Xerox>
> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?
I think not. I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")
If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)?
What is the difference between (pathname x) and (parse-namestring x)?
What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?
The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant.
∂09-Oct-87 1419 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 14:07:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:07:23 PDT
Date: 9 Oct 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 9 Oct 87 12:25 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871009-140723-1578@Xerox>
> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?
I think not. I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")
If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)?
What is the difference between (pathname x) and (parse-namestring x)?
What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?
The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant.
∂09-Oct-87 1457 Masinter.pa@Xerox.COM Issue: STREAM-CLASS-ACCESS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 14:56:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:57:30 PDT
Date: 9 Oct 87 14:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: STREAM-CLASS-ACCESS
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871009-145730-1702@Xerox>
(This issue was called FOLLOW-SYNONYM-STREAM in the original message by
KMP).
I vaguely remember this being discussed before but cannot find the mail.
I would prefer an extension for accessing the constructed streams that
treated them as if they were constructed by DEFSTRUCT or DEFCLASS, viz:
As if: (defstruct (synonym-stream (:constructor (make-synonym-stream
(symbol))) symbol)
=> (make-synonym-stream symbol) as in CLtL
(synonym-stream-p object)
(synonym-stream-symbol synonym-stream)
As if: (defstruct (broadcast-stream (:constructor (make-broadcast-stream
(&rest streams))) streams)
=> (make-broadcast-stream &rest streams) is in CLtL
(broadcast-stream-p object)
(broadcast-stream-streams broadcast-stream)
As if: (defstruct (two-way-stream (:constructor (make-two-way-stream
(input-stream output-stream))
=> (make-two-way-stream input-stream output-stream)
(two-way-stream-p object)
(two-way-stream-input-stream two-way-stream)
(two-way-stream-output-stream two-way-stream)
(The reason that I think I remember previous mail is that I remember a
discussion of whether it should be input-stream output-stream or just
input and output to shorten the names two-way-stream-input and
two-way-stream-output.)
(defun follow-synonym-stream (stream)
(if (synonym-stream-p stream)
(follow-synonym-stream (symbol-value (synonym-stream-symbol
stream)))
stream))
∂09-Oct-87 1524 Masinter.pa@Xerox.COM Issue: DEFINITION-FUNCTIONS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 15:23:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 15:20:50 PDT
Date: 9 Oct 87 15:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFINITION-FUNCTIONS
to: cl-cleanup@Sail.stanford.edu
Message-ID: <871009-152050-1749@Xerox>
I promised I would submit a proposal for "named definitions" for making
documentation etc more extensible in Common Lisp. I don't have a formal
proposal, but I've been sitting on this very rough draft...
- - - -
A "definition type" a symbol, like one of the following
function (including defun, defmacro, define-modify-macro...)
setf
variable
type
Definition types are used by several functions, including DOCUMENTATION.
A defining form, such as a form introduced with DEFUN, DEFSTRUCT, or
whatever, is said to give a given definition type to a specific name.
Frequently, a definition name is a symbol, but need not be.
(definition-type form)
Given a form (such as DEFUN, DEFMACRO and the like) returns the
type of thing defined by it.
(Can be either a form or else the symbol that introduces such a
form).
DEFSTRUCT, DEFTYPE => TYPE
DEFMACRO, DEFUN, DEFINE-MODIFY-MACRO, ... => FUNCTION
DEFSETF => SETF
DEFVAR, DEFPARAMETER, DEFCONST => VARIABLE
(definition-name form)
Given a form (no symbol allowed), returns the name of the thing
defined. Often SECOND, but e.g.
with DEFSTRUCT might do more processing.
(documentation name definition-type)
As before, type can be any definition type.
(delete-definition name definition-type)
delete all effects of name having a definition of type
(delete-definition name 'function) replaces (fmakunbound name)
(delete-definition name 'variable) replaces (makunbound name)
For adding more:
(def-definition-type type-name description &key undefiner)
Define type-name as a new kind of definition type.
Undefiner is a function which will remove a definition
(defdefiner definer-name type &key undefiner name-function)
says that definer-name defines things of type.
Undefiner says how to remove 'em
name-function, defaults to second, says, given an expression
which starts with definer-name, what the name of the thing is, e.g.,
(defdefiner defun function :undefiner #'fmakunbound :name-function
#'second)
(defdefiner defstruct type :undefiner #'si:remove-structure-definition
:name-function #'(lambda (x) (if (consp (second x)) (car (second x))
(Second x)))))
Note that when you undefine a name using delete-definition, *all* of
the known undefiners
(both the general one supplied with def-define-type and the specific
one defined
for each definer with defdefiner) are applied. The undefiner should not
error
if there is no definition.
function is defined by (DEFINE-MODIFY-MACRO DEFMACRO DEFUN)
type is defined by DEFTYPE DEFSTRUCT
variable is defined by DEFCONSTANT DEFPARAMETER DEFVAR
setf is defined by DEFSETF and DEFINE-SETF-METHOD
define-type is defined by DEF-DEFINE-TYPE
(ed name &optional type)
Optional type allows you to say which definition if there is more than
one.
- - - - - - - - - - -
The following make sense in some environments:
(has-definition-p name definition-type &key)
True if name has some definition of given type
(symbol-definition-types name)
Return list of all types for which name has a definition
- - - - - - - - -
With the error proposal, DEFINE-PROCEED-FUNCTION would define function,
too.
With CLOS, DEFCLASS would define a class.
This is awkwardly said, so I may have to explain it better: definers are
for things that define the *whole thing*, for which other definitions
are mutually exclusive. Thus, a defmethod doesn't define the generic
function, it only defines a piece of the generic function. So (defmethod
frob ((a widget) ...) ...) can't be a "definer" for the function frob.
There is some design choice of whether it is a definer for the function
(:method frob widget) (since definition names need not be symbols) or
whether it is the definer for the method (frob widget). I think this
need not be nailed down by the definition protocol.
I think this is separate from the "function spec" proposal because
"function specs" have to do with identifying pieces of executable code
which might have breakpoints, etc. assigned to them.
∂09-Oct-87 1524 Masinter.pa@Xerox.COM Issue Status (reply solicited)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 15:24:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 15:22:42 PDT
Date: 9 Oct 87 15:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue Status (reply solicited)
to: CL-CLEANUP@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871009-152242-1753@Xerox>
This is a revised version of the status file I sent out 22-Sep-87. I
have now gone through the mail I have on each issue, and attempted to
reflect what I think the current status is. As usual, if you want a copy
of the issue to refresh your memory or your mail archive, let me know.
(Someday I will be able to store these on a directory you have access
to.)
In some cases, I've indicated a question ???? on whether an item is
ready to release. I'd like everyone to reply, either with an accept,
don't care, or object on each releasable item.
Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: Please reply.
~ Tabled until resubmitted, i.e., no immediate action proposed.
In particular, if it says "???? Ready for release with endorsement", I
propose to edit the last submitted version of the proposal as sent to
CL-CLEANUP to include the statement that the cleanup committee endorses
the proposal, and send it on to X3J13. A simple one-line "please don't
release yet" reply will suffice.
!
* Proposal format (Version 12)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
???? Release version 12 with "Related issues" field?
ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Need volunteer to revise, clarify :displaced-to ommitted
same as :displaced-to nil.
Not ready for release.
ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
(p 297) "Specify that the fill pointer is ignored for the
purposes of deciding whether a given element of a new array
resulting from ADJUST-ARRAY should take its value from the
old array contents or from the specified :INITIAL-ELEMENT."
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
APPEND-DOTTED (version 1/27 Jul 87)
Sumbitted by KMP.
Need mod to Current Practice
Mention (append () t), clarify NCONC?
Not ready for release.
APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file)
(p 322) At end of second paragraph on *APPLYHOOK*,
clarify that the apply hook function is not used
when special forms are evaluated.
Need volunteer[lmm?] to submit.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
The summary says Version 2, but I only have version 1 on file.
Not ready for release
???? Does anyone else have a version 2? Or was this wishful thinking?
{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Postponed pending error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
CONSTANT-SIDE-EFFECTS (not yet submitted)
(it is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Need volunteer to submit
DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
DEFINITION-FUNCTIONS (not yet submitted)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
Very preliminary.
{ DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Await object proposal.
{ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Await object proposal.
* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
(Documentation string is not evaluated.)
Submitted, no replies
???? Ready for release with endorsement?
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13/Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Need volunteer to submit.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Postpone pending FUNCTION-TYPE resolution &
handle remainders.
EXPORT-COORDINATION (no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Not yet formally submitted.
Looking for proposal to make package manipulation lexical.
{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just an open
file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting
to STRING-CHAR for non-stream arguments and to the element-type of the
stream for a stream argument."
Need volunteer to write up.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?
FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer to write up.
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
Need volunteer to submit.
FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace
etc) Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
???? release with endorsement
{ IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
{ IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
Awaiting error proposal
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Rewrite using CLOS terminology ("named argument")
instead of "keyword argument".
Need volunteer to rewrite
LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
LOAD-TIME-EVAL (Version 2, 17-JUL-87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
No discussion after Version 2.
???? ready for release with endorsement ?
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
re-extract from environment-arguments?
???? drop this issue ?
* OPEN-KEYWORDS-EXISTS (Version 1/17-Jul-87)
No discussion.
???? Ready for release ?
* PATHNAME-STREAM (Version 4)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
???? Ready for release ?
PATHNAME-SUBDIRECTORY-LIST (Version 1/18-Jun-87)
How to deal with subdirectory structures in pathname functions?
Proposal for :SUBDIRECTORY rejected; make :DIRECTORY a structure?
Needs revision
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
Needs to be revised, extend language, clarify
which functions are affected, etc.
PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components,
etc in pathname functions
PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction
must or even ought to work."
???? Disposition?
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
This got sidetracked. Lets try to hash this one out.
~ PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
PUSH-EVALUATION-ORDER (not yet submitted)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Also INCF, PUSHNEW, etc.
(Mail 20 May 87)
(cf SETF-METHOD-FOR-SYMBOL).
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Found some discussion dated Feb 87.
???? Pitman will revise & resubmit. ?
SETF-METHOD-FOR-SYMBOL (Version 1, 21-Sep-87)
In discussion.
"Maybe we should fix the definition for setf of ldb rather than
the values returned for symbol?"
Not ready for release.
SETF-FUNCTION-VS-MACRO (not yet submitted)
Proposal in circulation on CLOS discussion for allowing
(DEFUN (SETF FOO) (new-value ... arguments) ...)
"Fixing our problems with setf"
* SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2, 28-Apr-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
No discussion since May-87
???? Release GENERALIZE option?
* SHADOW-ALREADY-PRESENT (Version 2, 27 Aug 87)
Revised according to discussion
???? Ready for release?
{ SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
~ SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 9-Mar-87)
(What package are *features* in?)
Mild support for :KEYWORD
???? Report out with only :KEYWORD proposal?
SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must be
initially bound to synonym streams to *TERMINAL-IO*; demote this to the
level of an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX redirection to win."
Need volunteer to submit
STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end of
the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
Gabriel will revise & resubmit?
∂15-Oct-87 1411 @STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87 14:10:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 256462; 15 Oct 87 17:11:02 EDT
Date: Thu, 15 Oct 87 17:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19871015211100.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
ISSUE: SETF-FUNCTION-VS-MACRO
REFERENCES: setf rules for what -place- can be (pp.94-7)
compile function (p.438)
defun macro (p.57)
disassemble function (p.439)
documentation function (p.440)
fboundp function (p.90)
flet special form (p.113)
fmakunbound function (p.92)
ftype declaration (p.158)
function special form (p.87)
function declaration (p.159)
inline declaration (p.159)
notinline declaration (p.159)
labels special form (p.113)
symbol-function and setf of symbol-function (p.90)
trace macro (p.440)
untrace macro (p.440)
CATEGORY: ADDITION
EDIT HISTORY: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The functions,
macros, and special forms defined in CLtL and listed in the References
section above need to be enhanced to accept such lists in addition to
symbols as function names, so that setf functions can be defined and
manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
TEST CASE: (really more examples than test cases)
;If setf of subseq was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
defsetf can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they have setting functions named (SETF reader). I don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
CONVERSION COST:
None, this is an upward-compatible change.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question, however by
stressing setf functions rather than setf macros SETF could become
easier to teach.
DISCUSSION:
Note that in Common Lisp, setf macroexpansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
Lexically local setf macros, that is, a cross between defsetf and
macrolet. This does not appear to be logically necessary. Do all three
ways of defining lexically global setf macros need local counterparts?
Should we define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
Should we enhance the definition of global setf macros, for example to
say that (macro-function '(setf foo)) returns an expander function that
takes two arguments and returns five values?
Should we introduce a new name for symbol-function, since it accepts
non-symbols now?
∂15-Oct-87 1725 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:24:59 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 15 Oct 87 20:21:44-EDT
Date: Thu, 15 Oct 1987 20:21 EDT
Message-ID: <FAHLMAN.12342792040.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: Msg of 15 Oct 1987 17:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO). This seems like a more radical change than is really necessary to
accomplish the stated purposes. It is a considerable extension to the
idea of a "function name", at least for standard Common Lisp
implementations that do not implement Lisp machine style function-specs.
Would it not be simpler to introduce a new setf-able access function
GET-SETF-FUNCTION which takes a symbol and returns the associated SETF
function? Under Moon's proposal a SETF form expands into something like
(funcall #'(setf foo) ...). This would become (funcall
(get-setf-function foo)...). I assume that in either case one must use
an explicit funcall and not just drop this "name" into the car-position
of an expression to be evaluated.
The one problem I can see with this alternative proposal is that it
there is no very good way to do something like FLET for the setf
function if there is not a name-like entity that can be bound. Is that
the reason for introducing this new kind of "name" instead of just
setting up the association with a setf-able function? Of course, we
could arbitrarily add some tweak to FLET that would locally rebind the
setf-function, but maybe Moon's scheme is more regular after all.
If we do go ahead with Moon's proposal in its current form, it would be
a good idea to address this concern and why something like the
alternative discussed here is not a better choice.
I assume that this would not preclude the addition of something like the
function specs that are present on the Lisp machine? If we finally
decide that Common Lisp is going to remain a Lisp-2, then we might want
to look at that whole issue again.
-- Scott
∂15-Oct-87 1738 Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:38:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256662; Thu 15-Oct-87 20:39:42 EDT
Date: Thu, 15 Oct 87 20:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12342792040.BABYL@C.CS.CMU.EDU>
Message-ID: <19871016003933.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Oct 1987 20:21 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO).
Would it not be simpler to introduce a new setf-able access function
GET-SETF-FUNCTION which takes a symbol and returns the associated SETF
function?
The CLOS committee tried that for a long time, but it doesn't work.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF or something.
The one problem I can see with this alternative proposal is that it
there is no very good way to do something like FLET for the setf
function if there is not a name-like entity that can be bound.
Precisely. That's the reason for making the name explicit.
I assume that this would not preclude the addition of something like the
function specs that are present on the Lisp machine?
Right. There could be other function names that are not symbols, however
we don't really need to propose any others for CLOS.
I assume that in either case one must use
an explicit funcall and not just drop this "name" into the car-position
of an expression to be evaluated.
Yes, the extra complexity of allowing something new in the car of a form
didn't seem to be justified. I guess I should have listed that among the
rejected ideas at the end.
∂15-Oct-87 1746 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87 17:46:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 15 Oct 87 20:46:42-EDT
Date: Thu, 15 Oct 1987 20:46 EDT
Message-ID: <FAHLMAN.12342796585.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: Msg of 15 Oct 1987 20:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
OK, Moon's proposal looks to me like the right way to go. It would be
useful to address the alternative I raised in the proposal and the
arguments against it, just so that N other people won't bring up the
same idea.
-- Scott
∂16-Oct-87 0107 peck@Sun.COM Re: Issue: PUSH-EVALUATION-ORDER
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 01:07:25 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA01645; Fri, 16 Oct 87 01:02:58 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA21892; Fri, 16 Oct 87 01:06:59 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA04926; Fri, 16 Oct 87 01:07:15 PDT
Message-Id: <8710160807.AA04926@denali.sun.com>
To: cl-cleanup@Sail.stanford.edu
Subject: Re: Issue: PUSH-EVALUATION-ORDER
In-Reply-To: Your message of 09 Oct 87 13:47:00 -0700;
<871009-134727-1519@Xerox> .
Date: Fri, 16 Oct 87 01:07:11 -0700
From: peck@Sun.COM
Issue: PUSH-EVALUATION-ORDER
References: CLtL pages 99 vs 270
Category: CLARIFICATION
Edit History: Jeff Peck, 15-Oct-1987, (version 1)
Problem Description:
In the form: (PUSH (ref1) (CAR (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Other macros that manipulate generalized variables include ... PUSH
...
Macros that manipulate generalized variables must guarentee the "obvious"
semantics: subforms of generalized-variable references are evaluated ...
in exactly the same order as they appear in the *source* program."
[That is, the sub-forms of Place should be evaluated once, left to right.]
"The expansion of these macros must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the subforms of the reference."
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
This paragraph and a discussion of SETF on the previous pages may also be
interpreted as requiring that *all* argument forms of such macros should
be evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."
That is, the effect of the form (PUSH Item Place) is to evaluate
(SETF Place (CONS Item Place)) but with subforms of Place only evaluated once.
Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form. Should the PUSH form have primacy over the
obvious SETF form with respect to the left-to-right evaluation?
Are all subforms in a macro argument list guarenteed to be evaluated in
order, or only those subforms representing generalized variable references?
Test Case:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
---versus---
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Proposal: PUSH-EVALUATION-ORDER:REDEFINE-PUSH
The form of PUSH is (PUSH Place Item).
Rationale:
PUSH is basically defined in the wrong order with respect to the obvious
implementation. Other generalized variable access functions are defined
with the Place form preceding the Value form. Accept for the natural visual
clue that PUSH should attach Item "in front" of Place, it would be more
natural to write (PUSH Place Item) and be parallel to SETF forms.
Discusion:
Never mind, this would break reams of existing code...
Proposal: PUSH-EVALUATION-ORDER:PLACE-FIRST
Page 270 should be modified to read:
"(PUSH Item Place) is equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once."
and
"(PUSHNEW Item Place :test P) is equivalent to
(SETF Place (ADJOIN Item Place :test P)) except that the subforms of
Place are evaluated only once."
Rationale:
The wording of CLtL on page 99 does not disallow or contradict this
interpretation. The wording of page 270 is already very close to this.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
Page 270 should be modified to read:
"(PUSH Item Place) is generally equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once, and Item
is evaluated before Place."
and
"(PUSHNEW Item Place :test P) is generally equivalent to
(SETF Place (ADJOIN Item Place :test P)) except that the subforms of
Place are evaluated only once, and Item is evaluated before Place."
Page 99 should be modified to explain explicitly that *all* argument
forms of *any* macro that ever uses generalized variable references, *must*
evaluate in left to right order as appearing in the source.
Specifically, the phase "subforms of the reference" which appears
several times should be changed to something like:
"subforms of the [generalized-variable manipulating macro] arguments".
Perhaps PUSH should be used as an example instead of the over worked SETF.
Rational:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended definition
of "obvious semantics" for all macros.
Current-practice:
PLACE-FIRST: Lucid, Franz and Kyoto evaluate Place then Item.
ITEM-FIRST: Symbolics evaluates Item then Place.
Adoption Cost:
Minimal, PUSH could simply be defined by the appropriate macro.
Cost of non-adoption:
Obvious programs may be non-portable. Although it should be rare that
order of evaluation will effect actual operation. Occasional programs may
get different results on Symbolics.
Benefits:
The implementation and semantics of PUSH become obvious to all.
With ITEM-FIRST, it is obvious when macros wrapped around PUSH will
evaluate their arguments in the proper order, no exceptions need to be made.
Esthetics:
Most folks won't notice. For true esthetics, see REDEFINE-PUSH.
Discussion:
David Moon (Symbolics) argues that the unstated intention of page 99
is the definition of the language, while admitting that:
"The quoted paragraphs could be taken to restrict order of evaluation only
of the subforms of (CAR (ref2)), not all of the subforms of the PUSH form."
∂16-Oct-87 0936 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PUSH-EVALUATION-ORDER
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 87 09:35:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 257095; Fri 16-Oct-87 12:35:53 EDT
Date: Fri, 16 Oct 87 12:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PUSH-EVALUATION-ORDER
To: peck@Sun.COM
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <8710160807.AA04926@denali.sun.com>
Message-ID: <19871016163545.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 16 Oct 87 01:07:11 -0700
From: peck@Sun.COM
I favor PUSH-EVALUATION-ORDER:ITEM-FIRST. I've always believed that
on page 99 of CLtL, "subforms of generalized-variable references" is
a typographical error for "subforms of macros that manipulate generalized
variable references." I only wish this typo had been caught before
the book was published. Note the paragraph a little further down the
page "As an example of these semantic rules, in the generalized-variable
reference (setf reference value), the value form must be evaluated after
all the subforms of the reference because the value form appears to the
right of them." In this single sentence, the term "generalized-variable
reference" is used both to mean a setf-able place and a form that invokes
setf. Confusing, isn't it? However, I don't see how this paragraph
can be interpreted any other way than that these rules govern the order
of evaluation of all the subforms of one of these macros, not just the
subforms inside "place".
∂16-Oct-87 1106 sandra%orion@cs.utah.edu compile-time effects of top-level forms
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:06:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA25495; Fri, 16 Oct 87 12:06:14 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12450; Fri, 16 Oct 87 12:05:57 MDT
Date: Fri, 16 Oct 87 12:05:57 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710161805.AA12450@orion.utah.edu>
Subject: compile-time effects of top-level forms
To: cl-cleanup@sail.stanford.edu
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu)
V2, 15 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu)
Related issues: none
Problem description:
CLtL currently leaves several issues unresolved regarding the compile-time
handling of top-level forms such as DEFMACRO and DEFVAR. The purpose of
this proposal is to ensure that all CL implementations support usages
which appear to be standard programming practices.
This proposal addresses only the semantics of top-level defining forms
as it affects compilation of subsequent forms in the same file. Specifically,
this proposal does *not* attempt to specify:
(1) Compile-time behavior of defining forms which do not appear at
top-level within the file being compiled.
(2) Inheritance or separation of the compiler environment from the normal,
interpreter environment; or inheritance of the compiler environment
across calls to COMPILE-FILE.
Proposal:
Certain defining macros, appearing at top-level within a file being
processed by COMPILE-FILE, normally have compile-time side effects which
affect how subsequent forms in the same file are compiled. As an example,
DEFVAR should store information that tells the compiler that bindings to
the named variable that appear later in the file should be made special
bindings, rather than the default lexical bindings.
In some implementations, compile-time definitions may be handled
differently than those which would occur if the file was loaded in the
usual way. It should not be assumed that the compile-time effects of the
defining forms remain in place after compilation is completed. In
particular, an implementation may or may not make the definitions available
to the interpreter or to further calls to COMPILE-FILE.
The defining forms which have compile-time side effects are as follows:
DEFTYPE: Type names defined via DEFTYPE must be recognized as valid in
subsequent type declarations.
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly. The body of the macro (*not* the expansion) must be evaluable
at compile time.
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as checking
the number of arguments on calls). Portable code should not rely on DEFUN
making the function definition available at compile time.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value form
must not be evaluated at compile time.
DEFCONSTANT: An implementation may choose to store information about the
variable for the purposes of compile-time error-checking (such as checking
for rebinding of or assignment to the variable). An implementation may also
choose to evaluate the inital value form at compile time.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable at
compile time.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
Test Case:
;;; DEFTYPE
(deftype small-int () '(int 0 10))
(let ((x 0))
(declare (type (small-int x)))
(format t "Type a number between 0 and 10:")
(setq x (read))
(format t "The number is ~s.~%" x))
;;; DEFMACRO
(defmacro silly (x) `(car ,x))
(let ((y nil))
(format t "Type a list:")
(setq y (read))
(format t "The SILLY macro returned ~s.~%" (silly y)))
;;; DEFVAR and DEFPARAMETER
(defvar *v1*
(progn
(print "Defvar should print this at load time.")
'v1-global-value))
(defparameter *v2*
(progn
(print "Defparameter should print this at load time.")
'v2-global-value))
(defun test-defvar-and-defparameter ()
(format t "*v1* = ~s~%" *v1*)
(format t "*v2* = ~s~%" *v2*))
(let ((*v1* 'v1-special-binding-value)
(*v2* 'v2-special-binding-value))
(test-defvar-and-defparameter))
;;; DEFCONSTANT
(defconstant *v3*
(progn
(print "This may be printed at compile-time as well as load time.")
'v3-value))
;;; DEFSETF
(defsetf silly set-silly)
(defun set-silly (x value)
(if (y-or-n-p "Do you want to change the CAR of ~s to ~s?" x value)
(setf (car x) value))
value)
(setf (silly (list 'a 'b 'c)) 'j-random-luser)
;;; DEFSTRUCT
(defstruct person name age sex)
(defstruct (astronaut (:include person) (:conc-name astro-))
helmet-size
(favorite-beverage 'tang))
Rationale:
The proposal reflects standard programming practices. The primary purpose
of the proposal is to make an explicit statement that CL supports the
behavior that most programmers expect and many implementations already
provide.
The only reference to compile-time processing of defining forms in CLtL
appears to be in reference to DEFMACRO, on page 143, where it is stated
that macro definitions must be ``seen'' by the compiler before the first
use of the macro.
Current practice:
Many (probably most) Common Lisp implementations, including VaxLisp and
Lucid Lisp, are already largely in conformance.
Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL. There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.
Adoption Cost:
The expansions of defining macros typically store information on property
lists or in hash tables, where it is later accessed by the compiler. The
simplest way to achieve the required behavior is to modify the expansions
to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the forms which store
this information.
Cost of non-adoption:
The current vagueness in CLtL on compiler semantics can lead to unexpected
portability problems. At least one person commented on the original
version of the proposal with, in effect, "Doesn't CLtL already *say* that
somewhere?!?" The problem now is that what many people (even experienced
programmers) think are portable programming practices are actually not.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
Conversion Cost:
Minimal.
Esthetics:
Without a definite statement on the compile-time behavior of top-level
defining forms, programmers need to wrap an explicit EVAL-WHEN around all
such forms to guarantee consistent behavior across implementations. It
would be cleaner to specify a default behavior that does what people seem
to expect anyway.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive. The current version incorporates a couple
additional suggestions that were made by others, notably Robert Kerns.
-------
∂16-Oct-87 1107 sandra%orion@cs.utah.edu proposal for modifying behavior of REQUIRE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 11:06:55 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA25574; Fri, 16 Oct 87 12:06:57 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12462; Fri, 16 Oct 87 12:06:51 MDT
Date: Fri, 16 Oct 87 12:06:51 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710161806.AA12462@orion.utah.edu>
Subject: proposal for modifying behavior of REQUIRE
To: cl-cleanup@sail.stanford.edu
Issue: REQUIRE-PATHNAME-DEFAULTS
References: CLtL p. 188
Category: CHANGE, ADDITION
Edit history: V1, 15 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu)
Related issues: none
Problem description:
If an explicit pathname is not given to the function REQUIRE, it decides
what files to load in an implementation-specific manner. The proposal
specifies a portable mechanism for locating modules intended to augment
current nonportable mechanisms.
Proposal:
*REQUIRE-PATHNAME-LIST* [Variable]
The variable *REQUIRE-PATHNAME-LIST* is a list of pathnames. This
list is used by the function REQUIRE in determining where to look for
modules an explicit pathnames are not specified.
REQUIRE tests for the following cases:
(1) If the pathname argument is present and non-NIL, it is a single
pathname or a list of pathnames whose files are to be loaded in order, left
to right.
(2) A pathname is constructed from the module name and merged with
successive pathnames from the list *REQUIRE-PATHNAME-LIST*, until
a matching file is found and loaded.
(3) The system will determine, in some system-dependent manner, which files
to load. This will typically involve some central registry of module names
and the associated file lists.
Users will typically wish to push new pathnames onto the front of
*REQUIRE-PATHNAME-LIST* to specify alternate locations where modules
may be found.
Test Case:
Rationale:
Because of the wide variation between implementations, leaving it up to
REQUIRE to determine which files to load is very nonportable. Providing an
explicit pathname is often impractical as well; for example, the same code
may run under two implementations with different operating systems and
different file naming conventions; the modules may reside in different
places on different machines; or it may be desirable to support alternate
versions of some modules (such as a release version and an experimental
version).
This proposal provides a portable way of describing where modules can be
found. The value of the *REQUIRE-PATHNAME-LIST* can be established in a
startup or initialization file, keeping a system-specific detail separate
from portable code files. Allowing a search list rather than a single
default pathname gives users extra flexibility to customize the behavior of
REQUIRE. Moreover, the current default behavior is still supported for
those programs which depend on it.
Current practice:
The idea of using a search list for loadable modules is modeled after the
LoadDirectories* variable used by Portable Standard Lisp. PCLS, the CL
compatibility package layered on top of PSL, currently uses a variable
SYS:*REQUIRE-PATHNAME-LIST* as described in this proposal.
VaxLisp (under VMS) looks for a module with the specified name first in the
current directory, then in the place specified by the logical name
LISP$MODULES, then in LISP$SYSTEM.
Lucid's documentation does not specify how their implementation of REQUIRE
works. I was unable to get it to find modules except in
*DEFAULT-PATHNAME-DEFAULTS*.
KCL looks for modules only in *DEFAULT-PATHNAME-DEFAULTS*.
Adoption Cost:
The change is minor and isolated to a single function. Here is a suggested
implementation of REQUIRE:
(defvar *require-pathname-list* nil
"Where REQUIRE looks for modules if you don't give an explicit pathname.")
(defun require (module &optional pathname)
(cond ((member (string module) *modules* :test #'equal))
((consp pathname)
(dolist (p pathname)
(load p)))
(pathname
(load pathname))
((progn
(setq pathname (pathname module))
(some
#'(lambda (default)
(load (merge-pathnames pathname (pathname default))
:if-does-not-exist nil))
*require-pathname-list*)))
((load pathname :if-does-not-exist nil))
(t
(cerror "Nothing will be loaded."
"Module ~s could not be found."
module)))
module)
Cost of non-adoption:
Using REQUIRE in portable code is difficult. In KCL and Lucid, I was forced
to redefine REQUIRE in my startup file to get it to look for modules in
places other than *DEFAULT-PATHNAME-DEFAULTS*.
Benefits:
See above, under "Rationale".
Conversion Cost:
None. The proposal is entirely compatible with the existing definition.
Esthetics:
I'd ordinarily be the last person to propose extensions to Common Lisp, but
having to learn one feature that works under all implementations is better
than having to learn each implementation's own peculiar way of handling the
same situation.
Discussion:
I mentioned the idea of having a variable to specify where REQUIRE looks
for modules in passing on the CL mailing list. There were 2 positive
responses and no negative ones. Cutting.pa@xerox.com proposed a search
list rather than a single pathname, which is actually what I had in mind
anyway.
-------
∂18-Oct-87 1959 FAHLMAN@C.CS.CMU.EDU Issue: DEFINITION-FUNCTIONS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Oct 87 19:59:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 18 Oct 87 23:00:05-EDT
Date: Sun, 18 Oct 1987 23:00 EDT
Message-ID: <FAHLMAN.12343607303.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DEFINITION-FUNCTIONS
In-reply-to: Msg of 9 Oct 1987 18:20-EDT from Masinter.pa at Xerox.COM
Date: Friday, 9 October 1987 18:20-EDT
From: Masinter.pa at Xerox.COM
To: cl-cleanup at Sail.stanford.edu
Re: Issue: DEFINITION-FUNCTIONS
I promised I would submit a proposal for "named definitions" for making
documentation etc more extensible in Common Lisp.
Just going over some old mail and found this. I'd like to see a lot
more motivation for all this machinery. Does this really solve some
useful problem, or is it extensibility for its own sake?
-- Scott
∂18-Oct-87 2021 FAHLMAN@C.CS.CMU.EDU compile-time effects of top-level forms
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Oct 87 20:21:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 18 Oct 87 23:22:02-EDT
Date: Sun, 18 Oct 1987 23:21 EDT
Message-ID: <FAHLMAN.12343611292.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: compile-time effects of top-level forms
In-reply-to: Msg of 16 Oct 1987 14:05-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
I think that these proposals have to be considered by the compiler
committee (which has to be resuscitated somehow). I think that all of
the compiler issues need to be considered as part of a single coherent
package.
-- Scott
∂19-Oct-87 0731 sandra%orion@cs.utah.edu Re: compile-time effects of top-level forms
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 07:31:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08766; Mon, 19 Oct 87 08:31:14 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA02958; Mon, 19 Oct 87 08:31:07 MDT
Date: Mon, 19 Oct 87 08:31:07 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710191431.AA02958@orion.utah.edu>
Subject: Re: compile-time effects of top-level forms
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: sandra%orion@λcs.utah.eduλ (Sandra J Loosemore),
cl-cleanup@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>, Sun, 18 Oct 1987 23:21 EDT
I'm afraid that bundling together *all* compiler issues will mean it
will take so long to get agreement that nobody will care any more! (I
suspect that a lot of us have already reached that stage; I, for one,
certainly have a hard time getting excited about the semantics of
non-top-level DEFMACROs.) I purposely tried to formulate this proposal
to steer clear of controversial issues and give implementations maximum
freedom.
What I'm really after is a statement that CL does support -- and will
continue to support -- certain fairly standard programming practices.
To my mind, a partial statement on compiler semantics is better than
none at all. Since there seems to be such overwhelming agreement with
this proposal (as far as it goes), I don't think it would be
unreasonable to commit to it now, and use it as a starting point for
more sweeping compiler cleanup efforts later (if anybody ever gets
interested).
-Sandra
-------
∂19-Oct-87 0801 FAHLMAN@C.CS.CMU.EDU compile-time effects of top-level forms
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 08:01:43 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 19 Oct 87 10:51:06-EDT
Date: Mon, 19 Oct 1987 10:50 EDT
Message-ID: <FAHLMAN.12343736727.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: compile-time effects of top-level forms
In-reply-to: Msg of 19 Oct 1987 10:31-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
It is not necessarily true that dealing with the compiler issues as a
group, rather than a few at a time, would slow the process down. There
was a comprehensive compiler proposal on the table a year ago. Some
aspects of it were controversial, but it should not have taken more than
a couple of months to hill-climb to some sort of agreement. The problem
is that the proposal was tabled by the compiler committee chairman,
who apparently thought things were moving too fast. He has successfully
put an end to that danger.
I suppose it would goad things along a bit if the cleanup committee were
to usurp jurisdiction over a few of these issues and pretend to settle
them, but that really doesn't seem like a good way to get the process
back on track. Also, the cleanup committee has its own problems when it
comes to getting things done.
-- Scott
∂20-Oct-87 1208 KMP@STONY-BROOK.SCRC.Symbolics.COM :1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87 12:08:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259304; Tue 20-Oct-87 15:09:25 EDT
Date: Tue, 20 Oct 87 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Does anyone have an unambiguous reference to a passage that claims
that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
it's a number and I've heard people claim that this is a bug, but
I just looked and could not find any text which convinced me of this.
If no one can convince me, I'll write up a cleanup item.
∂20-Oct-87 1224 RAM@C.CS.CMU.EDU :1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 12:24:38 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 20 Oct 87 15:24:59-EDT
Date: Tue, 20 Oct 1987 15:24 EDT
Message-ID: <RAM.12344048730.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: :1
In-reply-to: Msg of 20 Oct 1987 15:08-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
How about pp339-341: "Any token that is not a potential number and
does not consist entirely of dots will always be taken as a symbol,
now and in the future; programs may rely on this fact."
":1" is not a potential number according to the rules on page 341.
Rob
∂20-Oct-87 1240 KMP@STONY-BROOK.SCRC.Symbolics.COM :1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87 12:40:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259340; Tue 20-Oct-87 15:41:25 EDT
Date: Tue, 20 Oct 87 15:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: Ram@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12344048730.BABYL@>
Message-ID: <871020154057.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Yeah, that's the kind of thing I was looking for. Seems
adequately unambiguous to me. Thanks.
Btw, I can't believe we said "and in the future". What a
strange thing to have promised. Not like I'm proposing changing
it or anything, but it's hard enough to legislate the present
without worrying about promises for the future...
∂20-Oct-87 1247 Masinter.pa@Xerox.COM Re: :1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 87 12:47:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 87 12:48:11 PDT
Date: 20 Oct 87 12:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: :1
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 20 Oct 87 15:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871020-124811-2217@Xerox>
Kent, "In general, the token is interpreted as a number if it satisfies
the syntax for numbers specified in Table 22-2." There is no : anywhere
in table 22-2. I thus don't see how that can possibly be taken as
including :1.
In addition, there is no way to read the description on p 341 to include
any tokens with : as potential numbers.
∂20-Oct-87 1350 gls@Think.COM :1
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 87 13:50:36 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 20 Oct 87 16:23:58 EDT
Received: by kali.think.com; Tue, 20 Oct 87 16:23:07 EDT
Date: Tue, 20 Oct 87 16:23:07 EDT
From: gls@Think.COM
Message-Id: <8710202023.AA28861@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Kent M Pitman's message of Tue, 20 Oct 87 15:08 EDT <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: :1
Date: Tue, 20 Oct 87 15:08 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Does anyone have an unambiguous reference to a passage that claims
that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
it's a number and I've heard people claim that this is a bug, but
I just looked and could not find any text which convinced me of this.
If no one can convince me, I'll write up a cleanup item.
See pages 343-344:
"If there is a single package marker, and it occurs at the beginning of the
token, then the token is interpreted as a keyword, that is, a symbol in the
:keyword package. The part of the token after the package marker must not
have the syntax of a number."
[Unfortunately this leaves the question of potential numbers vague at best.]
"All other patterns of package markers ... presently do not mean anything
in Common Lisp.... It is therefore an error to use such patterns in a
Common Lisp program. The valid patterns for tokens may be summarized as
follows:
nnnnn ...
xxxxx ...
:xxxxx ...
ppppp:xxxxx ...
ppppp::xxxxx ...
where nnnnn has the syntax of a number, and xxxxx and ppppp do not have the
syntax of a number."
So the token ":1" is an error and may be given any interpretation by
an implementation.
--Guy
∂20-Oct-87 1424 Moon@STONY-BROOK.SCRC.Symbolics.COM :1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87 14:24:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259443; Tue 20-Oct-87 17:23:42 EDT
Date: Tue, 20 Oct 87 17:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Ram@C.CS.CMU.EDU,
Masinter.pa@Xerox.COM, gls@Think.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<RAM.12344048730.BABYL@>,
<871020154057.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<871020-124811-2217@Xerox>,
<8710202023.AA28861@kali.think.com>
Message-ID: <19871020212343.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Tue, 20 Oct 87 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Does anyone have an unambiguous reference to a passage that claims
that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
it's a number and I've heard people claim that this is a bug, but
I just looked and could not find any text which convinced me of this.
Those people are wrong, see GLS's response below.
Date: Tue, 20 Oct 1987 15:24 EDT
From: Ram@C.CS.CMU.EDU
How about pp339-341: "Any token that is not a potential number and
does not consist entirely of dots will always be taken as a symbol,
now and in the future; programs may rely on this fact."
":1" is not a potential number according to the rules on page 341.
":1" is not a single token in Symbolics' implementation. Table 22-1
says : is a constituent, but that cannot be correct, since it would
forbid the extension to factored package prefixes such as
"foo:(bar baz quux)". : is really a macro character. It's hard, for
me anyway, to tell whether this is a simple error in the description
of read syntax in CLtL, or whether it means Symbolics chooses not to
conform to a part of the language we disagree with. Fortunately it
makes little or no difference to the portability of practical programs.
Date: Tue, 20 Oct 87 16:23:07 EDT
From: gls@Think.COM
So the token ":1" is an error and may be given any interpretation by
an implementation.
Agreed. No valid portable program may contain or depend on that syntax,
among numerous others.
∂21-Oct-87 1444 Masinter.pa@Xerox.COM Issue: TRACE-FUNCTION-ONLY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 87 14:41:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 87 14:41:29 PDT
Date: 21 Oct 87 14:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: TRACE-FUNCTION-ONLY
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871021-144129-3988@Xerox>
I took the liberty of renaming this issue since the "problem" is broader
than CLOS, but this is otherwise as submitted.
----- Begin Forwarded Messages -----
Return-Path: <kempf%hplabsz@hplabs.HP.COM>
Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 21 OCT 87
10:00:05 PDT
Received: from hplms2 by hplabs.HP.COM with SMTP ; Wed, 21 Oct 87
09:59:19 PDT
Received: from hplabsz.hpl.hp.com by hplms2; Wed, 21 Oct 87 09:58:43 pdt
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Wed, 21 Oct 87 10:58:12 pdt
To: Masinter.pa
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: TRACE Proposal
X-Mailer: mh6.5
Date: Wed, 21 Oct 87 09:58:09 PDT
Message-Id: <24566.561833889@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
Larry:
Here is a copy of the proposed modifications to TRACE, which
were discussed at the September CLOS committee meeting. I have not
included the TRACE-EXECUTION proposal, since it is a generic function,
similar to PRINT-OBJECT, and its disposition was not clear at the
meeting.
I hope this gets to you in time for the November meeting. If
not, apologies: OOPSLA and recovery took longer than expected.
Jim Kempf
-------------------------------------------------------------------------------
Issue: TRACE-CLOS
References: trace macro pp. 440-441
Category: MODIFICATION
Edit history: Version 1, 21-Oct-87 Kempf
Problem description:
With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of
particular
methods to be traced, rather than invocation of the entire generic
function.
In addition, the current specification of TRACE does not allow tracing
of functions associated with SETF "methods", of macro functions,
nor of lexically defined functions or functions invoked via. their
function definition objects. While this proposal does not attempt
to address the latter problems, since identification and/or tracing of
these
is likely to be implementation dependent, it does leave
open the option for those implementations which can arrange it. Finally,
some implementations of Common Lisp have extended TRACE to take an
option
which puts the system into a break loop after the trace information has
been
printed. This proposal adds that capability to the standard.
Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)
(Font Note: UPPERCASE indicates bold, _this_ indicates italic)
TRACE _function-spec_ &KEY (:BREAK NIL) _[Macro]_
TRACE
UNTRACE _function-spec_ _[Macro]_
UNTRACE
Invoking TRACE with a function specification causes the function
specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. If the keyword argument :BREAK is T, then the BREAK
function will be called after the trace information is printed.
UNTRACE undoes any tracing. Calling TRACE without any arguments
prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.
A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent;
however,
every implementation is required to support the following:
_symbol_-Invocations of the function or macrofunction named by
_symbol_ via. _symbol_ as a global name are traced.
(METHOD _generic-function-name-specification_
_{method-qualifiers}_*
_parameter-specializer-name-list_
)
If the method whose parameter specializer list, generic function
name specification, and method qualifiers are listed is tracable,
then invocations through the generic function name specification
will be traced.
(SETF _symbol_)-If the SETF function having the name specification
is tracable, it will be traced (see proposal SETF-CLOS for
more information on SETF name specifications).
Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.
Rationale:
Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods.
Current practice:
Some Common Lisp implementations have extended TRACE syntax to
allow specification of breaks. Currently, the TRACE macro is
specified to take any number of symbols.
Adoption Cost:
The syntax of the TRACE macro will take only one function specification
in order to accomodate the :BREAK key. But, since TRACE tends to
be used interactively at the command langauge level, the impact
on existing code should be slight.
Cost of non-adoption:
Without this, implementation dependent ways of specifying the
:BREAK option would continue to be used. In addition, most
implementors would probably add their own syntax for allowing
programmers to obtain information on individual method invocation.
Benefits:
Allow programmers to obtain information on individual method
invocations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros.
----- End Forwarded Messages -----
∂21-Oct-87 1741 FAHLMAN@C.CS.CMU.EDU Issue: TRACE-FUNCTION-ONLY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 17:41:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 21 Oct 87 20:41:32-EDT
Date: Wed, 21 Oct 1987 20:41 EDT
Message-ID: <FAHLMAN.12344368508.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: TRACE-FUNCTION-ONLY
In-reply-to: Msg of 21 Oct 1987 17:40-EDT from Masinter.pa at Xerox.COM
(Kempf should probably be in on his discussion, but I don't have a
usable return address for him.)
My first reaction to this proposal was that TRACE is part of each
implementation's environment, and that since it does not affect portable
code, it should not be part of the spec. OK, we put TRACE into the
manual, and this has the benficial effect that in a new implementation
you know that the thing called TRACE is what you want to find out about
when you need this facility. But we should not try to constrain it any
further.
My second reaction was that I'd really like any implementaiton I use to
support tracing of generic functions, methods, and (if we adopt the
SETF-function proposal) these new function-spec forms. For that matter,
if we get deeper into the function-spec game, TRACE should follow. So
maybe putting this requirement into the standard is not so bad after all
-- it's one way of goading companies that might be slow to react
otherwise because their own people aren't deeply into CLOS yet.
So I'd be willing to go along with that part of the proposal. However,
I think that the :BREAK stuff does not belong here. If you want to
propose that as a required extension, you should do it in a separate
proposal and try to provide a better justification than "some
implementations do this, so I've randomly tossed it in with the other
stuff".
If you add :BREAK in the way you propose, you are introducing a
gratuitous incompatibility with the syntax in CLtL, since now TRACE only
takes a single symbol or function-spec. An alternative is the scheme
used in CMU Common Lisp:
(trace [trace-form]*)
where the trace form is either a symbol naming a function or a list
whose car is a function-name symbol and whose CDR contains the options
to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
etc.
I think that we got this extended syntax from Maclisp and that lots of
other Common Lisp implementations follow it as well. I would like any
proposal for extensions to TRACE to be compatible with this extended
syntax, which I think is better than requiring a separate call to TRACE
for each named function. It might be ambiguous to allow arbitrary
function-specs to appear as trace forms -- do you want to trace the SETF
function of some symbol or SETF itself? -- but it would not be a problem
to allow an arbitrary function spec to appear in the car of a
trace-form, with implementation-specific keyword options allowed in the
CDR.
-- Scott
∂21-Oct-87 1752 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TRACE-FUNCTION-ONLY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 87 17:51:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260521; Wed 21-Oct-87 20:52:29 EDT
Date: Wed, 21 Oct 87 20:41 EDT
From: Fahlman@C.CS.CMU.EDU
Sender: FAHLMAN@C.CS.CMU.EDU
Subject: Issue: TRACE-FUNCTION-ONLY
To: Masinter.pa@XEROX.COM, kempf%hplabsz@hplabs.hp.com
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Oct 87 17:40 EDT from Masinter.pa@Xerox.COM
Message-ID: <19871022005229.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <FAHLMAN.12344368508.BABYL@C.CS.CMU.EDU>
Redirected-Date: Wed, 21 Oct 87 20:52 EDT
Redirected-by: Moon@STONY-BROOK.SCRC.Symbolics.COM
[This message has been redirected:
kempf%hplabsz@hplabs.hp.com should be a usable address for sending to Jim Kempf from CMU-C.
kempf%hplabsz@hplabs.hp.com has been added.]
(Kempf should probably be in on his discussion, but I don't have a
usable return address for him.)
My first reaction to this proposal was that TRACE is part of each
implementation's environment, and that since it does not affect portable
code, it should not be part of the spec. OK, we put TRACE into the
manual, and this has the benficial effect that in a new implementation
you know that the thing called TRACE is what you want to find out about
when you need this facility. But we should not try to constrain it any
further.
My second reaction was that I'd really like any implementaiton I use to
support tracing of generic functions, methods, and (if we adopt the
SETF-function proposal) these new function-spec forms. For that matter,
if we get deeper into the function-spec game, TRACE should follow. So
maybe putting this requirement into the standard is not so bad after all
-- it's one way of goading companies that might be slow to react
otherwise because their own people aren't deeply into CLOS yet.
So I'd be willing to go along with that part of the proposal. However,
I think that the :BREAK stuff does not belong here. If you want to
propose that as a required extension, you should do it in a separate
proposal and try to provide a better justification than "some
implementations do this, so I've randomly tossed it in with the other
stuff".
If you add :BREAK in the way you propose, you are introducing a
gratuitous incompatibility with the syntax in CLtL, since now TRACE only
takes a single symbol or function-spec. An alternative is the scheme
used in CMU Common Lisp:
(trace [trace-form]*)
where the trace form is either a symbol naming a function or a list
whose car is a function-name symbol and whose CDR contains the options
to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
etc.
I think that we got this extended syntax from Maclisp and that lots of
other Common Lisp implementations follow it as well. I would like any
proposal for extensions to TRACE to be compatible with this extended
syntax, which I think is better than requiring a separate call to TRACE
for each named function. It might be ambiguous to allow arbitrary
function-specs to appear as trace forms -- do you want to trace the SETF
function of some symbol or SETF itself? -- but it would not be a problem
to allow an arbitrary function spec to appear in the car of a
trace-form, with implementation-specific keyword options allowed in the
CDR.
-- Scott
∂22-Oct-87 0741 KMP@STONY-BROOK.SCRC.Symbolics.COM DECLARE-MACROS (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 07:41:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260815; Thu 22-Oct-87 10:41:49 EDT
Date: Thu, 22 Oct 87 10:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871022104113.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In some cases, it may be desirable to ask a question about a
particular piece of code without actually modifying the code. Since
the presence of *MACROEXPAND-HOOK* in the language means that a call
to MACROEXPAND can be a destructive operation, some seemingly harmless
inquiry operations about an expression during program analysis can
risk destructively modifying the expression.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macroexpansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be expontential in the depth of nesting
unless a macro-expansion caching mechanism is added. For example,
certain efficiency problems in the Symbolics compiler have been traced
to this feature.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accomodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Make it illegal for a macro call to expand into a DECLARE form and be
recognized as such.
It should still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The advantages provided by the ability to have a macro form expand into
a declaration have been shown in practice to not be worth the price paid
elsewhere in the language.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Adoption Cost:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Conversion Cost:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY () `(DECLARE (SPEED 3) (SAFETY 0)))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL (DECLARE (SPEED 3) (SAFETY 0)) ,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
∂22-Oct-87 1150 Pavel.pa@Xerox.COM Re: DECLARE-MACROS (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 11:50:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 OCT 87 11:49:41 PDT
Date: Thu, 22 Oct 87 11:49:34 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DECLARE-MACROS (Version 1)
In-reply-to: <871022104113.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-114941-5200@Xerox>
I support this change. It was the cause of no small amount of grousing
by other developers of Xerox Common Lisp when they saw the complexities
it entailed in the interpreter, compiler, and macros. I think the
proposal states the situation correctly: ``This linguistic feature
provides some useful flexibility, but has a number of disadvantages''.
I think the problems far outweigh the value of the flexibility.
Pavel
∂22-Oct-87 1224 FAHLMAN@C.CS.CMU.EDU DECLARE-MACROS (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 12:24:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Oct 87 15:25:13-EDT
Date: Thu, 22 Oct 1987 15:24 EDT
Message-ID: <FAHLMAN.12344573036.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: DECLARE-MACROS (Version 1)
In-reply-to: Msg of 22 Oct 1987 10:41-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have suggested on several occasions that we eliminate macro ->
declaration expansion, and I still think that this would be a good idea.
It would have been an even better idea if it had happened earlier, but
my time machine has been confiscated by the reality police, so I can't
do much about that.
I think that there are several bits of hair in the language spec that we
added because of this "feature" and that we could flush if it goes away
-- environment args in various places, etc. It may be best to let these
things live on, however.
-- Scott
∂22-Oct-87 1259 KMP@STONY-BROOK.SCRC.Symbolics.COM COLON-NUMBER (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 12:58:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261173; Thu 22-Oct-87 15:59:38 EDT
Date: Thu, 22 Oct 87 15:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COLON-NUMBER (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
The message of 20 Oct 87 15:24 EDT from Ram@C.CS.CMU.EDU,
<8710202023.AA28861@kali.think.com>,
<871020-124811-2217@Xerox>,
<19871020212343.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8710221841.AA00236@kali.think.com>
Message-ID: <871022155903.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: COLON-NUMBER
References: Parsing of Numbers and Symbols (p339-341, 343-344)
Category: CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is unclear about whether a colon followed by a potential number
is a potential number. There are passages which seem to address this
issue unambiguously but fail.
Proposal (COLON-NUMBER:UNDEFINED):
Clarify that syntax involving a leading colon followed by a potential
number is not well-defined. That is, use of notation such as :1, :1/2,
and :2↑3 in a position where an expression appropriate for READ is
expected is an error.
Rationale:
This makes the status quo apparent.
Current Practice:
Some implementations, such as Symbolics Lisp, claim the right to
interpret this as an ``is an error'' situation where their
upward-compatible extension is to parse ``:1'' as the number 1
(incidentally, but uninterestingly, expressed in the KEYWORD package).
Other implementations tokenize ``:1'' as a single token, identify it
as a symbol, and then parse it as :\1 would be parsed.
Adoption Cost:
None. This clarification forces no implementations to change.
Benefits:
Programmer expectations that any useful behavior can be portably relied
upon in this pathological case should be soundly trounced.
Conversion Cost:
Slight. Some users may have mistakenly believed that this was an aspect
of the language that was guaranteed and may have written programs that
exploited that belief. Such incidences are probably very rare, however.
Also, even in the few cases where such code fortuitously worked,
implementations are likely to continue to support it so such code will
probably continue to fortuitously work in many of those rare situations.
Aesthetics:
Arguably a slight improvement in visual aesthetics. What was already
a pretty marginal syntax is discouraged.
Discussion:
Pitman supports this clarification. He thinks this issue is not a big
deal, but it does crop up often enough to be a nuisance. It would be
nice to have everyone acknowledge a unified position, even if that only
meant agreeing to disagree.
∂22-Oct-87 1303 FAHLMAN@C.CS.CMU.EDU COLON-NUMBER (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 13:03:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Oct 87 16:03:48-EDT
Date: Thu, 22 Oct 1987 16:03 EDT
Message-ID: <FAHLMAN.12344580093.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: COLON-NUMBER (Version 1)
In-reply-to: Msg of 22 Oct 1987 15:59-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
OK by me. This seems like as good a solution as any.
-- Scott
∂22-Oct-87 1358 Moon@STONY-BROOK.SCRC.Symbolics.COM COLON-NUMBER (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 13:58:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261258; Thu 22-Oct-87 16:58:54 EDT
Date: Thu, 22 Oct 87 16:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COLON-NUMBER (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871022155903.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871022205854.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with COLON-NUMBER:UNDEFINED.
∂22-Oct-87 1631 Masinter.pa@Xerox.COM administrivia
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 16:31:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 16:29:24 PDT
Date: 22 Oct 87 16:29 PDT
From: Masinter.pa@Xerox.COM
Subject: administrivia
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-162924-5708@Xerox>
Because of a death in my family, I've been only around minimally for the
last few weeks. I'm back now, and I hope to be able to gather up issues
to at least pass out copies at X3J13, although I don't think I'll be
able to mail any large collection of things out.
I sent out a message with "reply solicited", but didn't get any
responses. I suppose we need to have the real ballot items separated
out?
∂22-Oct-87 1645 Masinter.pa@Xerox.COM Re: DECLARE-MACROS (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 16:45:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 16:46:14 PDT
Date: 22 Oct 87 16:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DECLARE-MACROS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 22 Oct 87 10:41 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-164614-5748@Xerox>
I think this issue is ready to release with endorsement -- I recall (but
cannot easily find) a previous discussion of this on common-lisp where
the consensus was in favor of it.
Any objections?
∂22-Oct-87 1716 Masinter.pa@Xerox.COM Re: Issue: TRACE-FUNCTION-ONLY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 17:15:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 17:11:39 PDT
Date: 22 Oct 87 17:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: TRACE-FUNCTION-ONLY
In-reply-to: Fahlman@C.CS.CMU.EDU's message of Wed, 21 Oct 87 20:41 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-171139-5785@Xerox>
I have frequently felt a need to define a layer between Common Lisp the
Language and Common Lisp the Environment. It would probably make those
who are pushing for a "layered defintion" in ISO happy if we made the
division more explicit.
Certainly, in such a situation, TRACE, STEP, ***, and many other friends
would fit in the Environment rather than the Language portion. I imagine
that there might be different levels of conformance testing available
for Language and Environment -- it is notably difficult to generate
automatic testing code for environment features, implementations for
embedded systems might well not have environment features, etc.
The layering of the definition of CL is something not addressed by
X3J13, although the ISO groups seem to be pushing at it from the bottom
up. I'd hate to stall this proposal waiting on something as vague as
that.
I have no opinion on the various ways of expressing :BREAK except that
I'd like to see it in the language. Right now, I have to type (IL:BREAK
X) in Xerox Common Lisp.
By the way, XCL implements (trace (a :in b)) as a way of tracing the
calls to A which occur from B. This might fit into this proposal too,
although I don't know if it is something that is always implementable.
The form also admits (trace ((a b c) :in (d e f))) where lists are
multiplexed.
I don't have enough other Common Lisp environment manuals to do an
exhaustive Current Practice section, although I think that proper
consideration of this issue requires it.
∂22-Oct-87 1716 Masinter.pa@Xerox.COM Re: COLON-NUMBER (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 17:16:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 17:16:50 PDT
Date: 22 Oct 87 17:16 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: COLON-NUMBER (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 22 Oct 87 16:58 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-171650-5792@Xerox>
I'm vaguely uneasy that this is not really an issue, and is addressed in
CLtL although not explicitly enough, but I guess there is sufficient
sentiment (as evidenced by Kent taking the time to write it up) that we
should proceed.
I propose to edit this to say that the cleanup committee endorses this
proposal and bring along copies to X3J13.
Objections?
∂22-Oct-87 1732 Masinter.pa@Xerox.COM Re: Issue: DEFINITION-FUNCTIONS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 17:32:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 17:28:25 PDT
Date: 22 Oct 87 17:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DEFINITION-FUNCTIONS
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
18 Oct 87 23:00 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-172825-5809@Xerox>
>Just going over some old mail and found this. I'd like to see a lot
>more motivation for all this machinery. Does this really solve some
>useful problem, or is it extensibility for its own sake?
>-- Scott
Well, I can say that I use (a version of) this machinery frequently in
the Xerox Lisp environment, but I'm not sure it isn't because it also
interacts nicely with the residential environment.
One reason for mailing this proposal out was to allay suspicion that the
trace proposal and this one might interact.
>From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>Date: Thu, 6 Aug 87 14:10 EDT
>cc: common-lisp-object-system@SAIL.STANFORD.EDU, Masinter.pa
. . . .
>The Cleanup subcommittee of X3J13 were discussing something similar
>a while back, starting from a different point. The DOCUMENTATION
function
>of Common Lisp introduces the concept of "definition types", and this
>concept could be useful in other operations. For instance, it would be
>nice to be able to remove any definition (function, variable, type,
setf)
>through a uniform interface. "Definition type" and "function spec
type"
>are not the same concept, however there seems to be enough overlap here
>that some coordination is probably called for.
>I don't remember for sure, but I think Larry Masinter volunteered to
make
>a proposal for "definition types" when he got time.
∂22-Oct-87 1738 Masinter.pa@Xerox.COM Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 17:38:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 17:38:44 PDT
Date: 22 Oct 87 17:38 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of
Fri, 16 Oct 87 12:06:51 MDT
To: sandra%orion@cs.utah.edu, cl-cleanup@sail.stanford.edu
Message-ID: <871022-173844-5825@Xerox>
I certainly would like to see REQUIRE mean something, although I'm a
little uneasy about making it have such an operative rather than
semantic definition.
Be that as it may, I'm willing to report it out as endorsed.
I take GLS's recent message as an indication that some proposal is
called for here, although I don't know whether he likes this one.
Are there any other opinions, or can we release it?
∂22-Oct-87 1757 Masinter.pa@Xerox.COM Re: SETF-FUNCTION-VS-MACRO (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87 17:57:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 87 17:53:59 PDT
Date: 22 Oct 87 17:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 15 Oct 87 17:11 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <871022-175359-5842@Xerox>
I propose releasing this issue with the following changes to the
discussion section:
Add these paragraphs before the section "The following related features
were considered..." :
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
Add this paragraph to the end of "The following related features were
considered...":
Should one allow these extended function names in the car-position of
an expression to be evaluated? The extra complexity didn't seem
justified,
instead, an explicit funcall is required.
∂22-Oct-87 1840 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: SETF-FUNCTION-VS-MACRO (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 18:39:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261570; Thu 22-Oct-87 21:39:53 EDT
Date: Thu, 22 Oct 87 21:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: SETF-FUNCTION-VS-MACRO (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871022-175359-5842@Xerox>
Message-ID: <19871023013955.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 22 Oct 87 17:51 PDT
From: Masinter.pa@Xerox.COM
I propose releasing this issue with the following changes to the
discussion section....
Those amendments are fine with me. I was planning to add them myself,
and I apologize for being slow to get around to it.
∂22-Oct-87 1900 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87 18:54:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261580; Thu 22-Oct-87 21:51:55 EDT
Date: Thu, 22 Oct 87 21:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871022-173844-5825@Xerox>
Message-ID: <19871023015154.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 22 Oct 87 17:38 PDT
From: Masinter.pa@Xerox.COM
I certainly would like to see REQUIRE mean something, although I'm a
little uneasy about making it have such an operative rather than
semantic definition.
Be that as it may, I'm willing to report it out as endorsed.
At Symbolics we've had a lot of experience with this kind of thing on a
wide variety of file systems, and I don't think anything as simple as
this proposal will truly be portable across all systems. It can be
fairly difficult to construct module names that will work as expected as
file names on all the different file systems in the world. There are
length restrictions, character set restrictions, and upper case versus
lower case issues. Also the proposal codifies a fairly naive view of
how to use hierarchical file systems. Since the example in the proposal
shows that this can be implemented in 19 lines of code, I'd prefer a
proposal to remove REQUIRE from the language entirely (along with
PROVIDE), and let users who find this 19-line function adequate define
it themselves. Other users might define a different facility for
finding and loading programs.
However, since the proposal doesn't change the behavior of anything
unless you SETQ this new variable, the only way it makes Common Lisp
worse is if more people are misled into thinking that PROVIDE and
REQUIRE are going to do something useful for them. Thus if other
committee members feel that we ought to endorse this, I won't say
anything.
Also a quibble: in the example, (pathname module) should be
(pathname (string module)) so as not to interact with the
PATHNAME-SYMBOL issue.
∂22-Oct-87 2136 sandra%orion@cs.utah.edu Re: Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 21:35:31 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08970; Thu, 22 Oct 87 22:34:24 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA24625; Thu, 22 Oct 87 22:34:05 MDT
Date: Thu, 22 Oct 87 22:34:05 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710230434.AA24625@orion.utah.edu>
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS
To: David A. Moon <Moon@scrc-stony-brook.arpa>
Cc: Masinter.pa@xerox.com, sandra%orion@cs.utah.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 22 Oct 87 21:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
It can be
fairly difficult to construct module names that will work as expected as
file names on all the different file systems in the world. There are
length restrictions, character set restrictions, and upper case versus
lower case issues.
I've run into these myself, particularly the uppercase/lowercase
problem, which is more of an issue with symbols since print names are
generally uppercase and people like to use lowercase file names on
systems that care about such things. But this is a problem with
PATHNAME and PARSE-NAMESTRING, not modules specifically. We here at
Utah had terrible problems trying to figure out how to do PCLS on the
Cray under CTSS, where you can only have 6 character filenames, no
filetypes, and no directories!
-Sandra
-------
∂23-Oct-87 0709 gls@Think.COM COLON-NUMBER (Version 1)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 07:09:10 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 23 Oct 87 10:08:14 EDT
Received: by kali.think.com; Fri, 23 Oct 87 10:08:38 EDT
Date: Fri, 23 Oct 87 10:08:38 EDT
From: gls@Think.COM
Message-Id: <8710231408.AA01421@kali.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 22 Oct 87 16:58 EDT <19871022205854.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: COLON-NUMBER (Version 1)
Date: Thu, 22 Oct 87 16:58 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I agree with COLON-NUMBER:UNDEFINED.
Me, too.
∂23-Oct-87 0717 gls@Think.COM DECLARE-MACROS (Version 1)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 07:16:53 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 23 Oct 87 10:17:03 EDT
Received: by kali.think.com; Fri, 23 Oct 87 10:17:24 EDT
Date: Fri, 23 Oct 87 10:17:24 EDT
From: gls@Think.COM
Message-Id: <8710231417.AA01431@kali.think.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 22 Oct 87 16:46 PDT <871022-164614-5748@Xerox>
Subject: DECLARE-MACROS (Version 1)
Date: 22 Oct 87 16:46 PDT
From: Masinter.pa@xerox.com
I think this issue is ready to release with endorsement -- I recall (but
cannot easily find) a previous discussion of this on common-lisp where
the consensus was in favor of it.
Any objections?
Not from me. In fact, I wish to explicitly endorse KMP's proposal.
--Guy
∂23-Oct-87 0829 @Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM Re: Issue: TRACE-FUNCTION-ONLY
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 08:29:25 PDT
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Fri 23 Oct 87 08:23:13-PDT
Received: from hplms2 by hplabs.HP.COM with SMTP ; Fri, 23 Oct 87 08:26:40 PDT
Received: from hplabsz.hpl.hp.com by hplms2; Fri, 23 Oct 87 08:25:58 pdt
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Fri, 23 Oct 87 09:25:29 pdt
To: Fahlman@C.CS.CMU.EDU
Cc: Masinter.pa@XEROX.COM, kempf%hplabsz@hplabs.hp.com,
cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TRACE-FUNCTION-ONLY
X-Mailer: mh6.5
In-Reply-To: Your message of Wed, 21 Oct 87 20:41:00 -0400.
<19871022005229.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 Oct 87 08:25:25 PDT
Message-Id: <21096.562001125@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
Scott:
Larry forwarded your message. My address is: kempf@hplabs.hp.com.
> My first reaction to this proposal was that TRACE is part of each
> implementation's environment, and that since it does not affect portable
> code, it should not be part of the spec.
This was my first reaction also.
> However,
> I think that the :BREAK stuff does not belong here. If you want to
> propose that as a required extension, you should do it in a separate
> proposal and try to provide a better justification than "some
> implementations do this, so I've randomly tossed it in with the other
> stuff".
I've found being able to introduce a break after the printing of tracing
information in our Lisp to be an invaluable debugging tool, as have
other developers here. At the moment, they are beating my door down
for the same capability (along with simple tracing) for individual
methods, in the portable CLOS implementation. I can add this justification
to the proposal.
> If you add :BREAK in the way you propose, you are introducing a
> gratuitous incompatibility with the syntax in CLtL, since now TRACE only
> takes a single symbol or function-spec. An alternative is the scheme
> used in CMU Common Lisp:
> (trace [trace-form]*)
> where the trace form is either a symbol naming a function or a list
> whose car is a function-name symbol and whose CDR contains the options
> to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
> etc.
I originally proposed something like this and the concensus of the objects
committee seemed to be that a cleaner syntax would be to limit TRACE
to a single function specification, and add the keyword as a keyword
argument. The committee seemed to feel that including the keyword as
part of a list containing a function specification could become confusing
when the function specification was more than just a symbol.
As to the incompatibility with current Common Lisp, as you pointed out
in your note, TRACE is, to a large extent, part of the environment,
Changing the interface would probably have less effect than changing
something like, say, MAKE-ARRAY, since people tend to use TRACE interactively.
> I think that we got this extended syntax from Maclisp and that lots of
> other Common Lisp implementations follow it as well. I would like any
> proposal for extensions to TRACE to be compatible with this extended
> syntax, which I think is better than requiring a separate call to TRACE
> for each named function. It might be ambiguous to allow arbitrary
> function-specs to appear as trace forms -- do you want to trace the SETF
> function of some symbol or SETF itself? -- but it would not be a problem
> to allow an arbitrary function spec to appear in the car of a
> trace-form, with implementation-specific keyword options allowed in the
> CDR.
If you feel strongly about it (and nobody else feels strongly in the other
direction), I can resubmit the proposal with the interface as you've
requested.
While we're discussing this issue, another part of the proposal was to
include a generic function, called TRACE-EXECUTION, which took as an
argument an object representing an executable entity, like a method object,
generic function, function, symbol, etc. An implementation specific method
would run to arrange for tracing code to be inserted. Similar to
PRINT-OBJECT, all implementations would have to implement tracing using
this generic function. The advantage of this is that if someone extends
CLOS/CL by including a new funcallable object, like, for example, a
remote procedure call, debugging becomes extensible as well.
I originally did not submit this to the Cleanup-committee because it
seemed to be a CLOS exclusive issue (being a generic function) but maybe
I should have?
Jim Kempf kempf@hplabs.hp.com
∂23-Oct-87 0957 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 09:57:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 09:52:38 PDT
Date: 23 Oct 87 09:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 5)
TO: CL-Cleanup@sail.stanford.edu
CC: MASINTER.pa@Xerox.COM
Message-ID: <871023-095238-6542@Xerox>
In this version, I explicitly disallow synonym streams (and two-way,
echo, string, broadcast streams), and explicitly allow streams created
with open and with-open-file. I enhanced the discussion section, and
added a reference to p. 417 "the name returned represents the name used
to open the file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 4 by Masinter 8-Oct-87 (explicitly only open)
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a
pathname, but many sources or sinks of data that streams might be
connected to have no pathnames associated with them; for example,
streams created with MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many
such streams, there is no simple way to coerce such a stream to a
pathname.
Proposal PATHNAME-STREAM:FILES-ONLY:
Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN or WITH-OPEN-FILE. It is an error
to attempt to obtain a pathname from a stream created with
MAKE-SYNONYM-STREAM, MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM,
MAKE-ECHO-STREAM, MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM,
MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may
be, but is not required to be, the actual name of the file.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others return an empty pathname.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to
make them portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
Is a synonym stream whose target is an acceptable stream also
acceptable? This proposal says no: the clarification is to extend the
restriction expressed on p. 417 of CLtL ("a stream that is or was open
to a file") back to cover all of the functions that take pathname
arguments. Only streams that were created given pathnames are required
to have pathnames accessable.
Note that there is currently no way portable to determine whether a
stream has a pathname available.
∂23-Oct-87 1036 Masinter.pa@Xerox.COM Issue: PUSH-EVALUATION-ORDER (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 10:35:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 10:32:40 PDT
Date: 23 Oct 87 10:32 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@Sail.stanford.edu
Subject: Issue: PUSH-EVALUATION-ORDER (Version 2)
to: cl-cleanup@Sail.stanford.edu, peck@Sun.COM
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871023-103240-6617@Xerox>
I rewrote this proposal extensively; I removed all but the :ITEM-FIRST
proposal, extended it to include INCF, DECF, PUSHNEW, and macros which
are created with DEFINE-MODIFY-MACRO, and tried to write it as changes
to the language rather than changes to CLtL, etc.
Is this ready for release? Moon was the only one who responded.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables), p 270 (PUSH)
p. 201 (INCF, DECF).
Category: CLARIFICATION
Edit History: Jeff Peck, 15-Oct-1987, version 1.
Larry Masinter, 23-Oct-87, version 2.
Problem Description:
In the form: (PUSH (ref1) (CAR (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Other macros that manipulate generalized variables include ... PUSH....
Macros that manipulate generalized variables must guarentee the
"obvious"
semantics: subforms of generalized-variable references are evaluated
...
in exactly the same order as they appear in the *source* program."
That is, the sub-forms of Place should be evaluated once, left to right.
"The expansion of these macros must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the subforms of the
reference."
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
This paragraph and a discussion of SETF on the previous pages may also
be
interpreted as requiring that *all* argument forms of such macros should
be evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."
That is, the effect of the form (PUSH Item Place) is to evaluate
(SETF Place (CONS Item Place)) but with subforms of Place only evaluated
once.
Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form. Should the PUSH form have primacy over
the
obvious SETF form with respect to the left-to-right evaluation?
Are all subforms in a macro argument list guarenteed to be evaluated in
order, or only those subforms representing generalized variable
references?
The same question arises for other forms which manipulate generalized
variables, e.g., PUSHNEW, INCF, DECF, and those defined with
DEFINE-MODIFY-MACRO.
Test Case:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
If the subforms evaluate in left-to-right order, this will print 12
rather than 21.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
Explicitly state that for the macros that manipulate generalized
variables (PUSH, PUSHNEW, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF and
those defined with DEFINE-MODIFY-MACRO) the subforms of the macro
(including but not limited to those of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program.
For example, PUSH is expected to behave as if described as:
(PUSH Item Place) is generally equivalent to (SETF Place (CONS Item
Place))
except that the subforms of Place are evaluated only once, and Item
is evaluated before Place."
The phase "subforms of the reference" which appears several times in
CLtL should be made more specific to be "subforms of the
[generalized-variable manipulating macro] arguments".
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended
definition of "obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In
the form (PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place
then Item. Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Adoption Cost:
Minimal, PUSH could simply be defined by the appropriate macro.
Cost of non-adoption:
Obvious programs may be non-portable, although it should be rare that
order of evaluation will effect actual operation.
Benefits:
The implementation and semantics of PUSH become obvious to all.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this
clarification ensures consistency across the language.
Discussion:
David Moon (Symbolics) argues that the unstated intention of page 99
is the definition of the language, while admitting that:
"The quoted paragraphs could be taken to restrict order of evaluation
only
of the subforms of (CAR (ref2)), not all of the subforms of the PUSH
form."
No performance impact is expected; while some macro expansions may
appear to be more verbose, most compilers deal reasonably with the
required order of evaluation.
∂23-Oct-87 1046 RAM@C.CS.CMU.EDU Issue: PATHNAME-STREAM (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 10:46:20 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 23 Oct 87 13:46:43-EDT
Date: Fri, 23 Oct 1987 13:46 EDT
Message-ID: <RAM.12344817269.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-STREAM (Version 5)
In-reply-to: Msg of 23 Oct 1987 12:52-EDT from Masinter.pa at Xerox.COM
Date: Friday, 23 October 1987 12:52-EDT
From: Masinter.pa at Xerox.COM
To: CL-Cleanup at sail.stanford.edu
cc: MASINTER.pa at Xerox.COM
Re: Issue: PATHNAME-STREAM (Version
[...] I enhanced the discussion section, and added a reference to
p. 417 "the name returned represents the name used to open the
file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
I think that this should be read as a warning that PATHNAME on an open
stream doesn't necessarily return the truename of the file ultimately
written, or even necessarily the truename of any file that ever
existed or will exist.
If this is read as a strict requirement, then it is pretty clearly
wrong, since presumably if you do a RENAME-FILE on the stream, you want
PATHNAME of that stream to return the new name, rather than the name
it was originally opened with.
If you are trying to clean up the rot with streams as pathnames, you
should carefully look over section 23.3 pp 423-425, as many of these
functions are suggested to do something semantically different with a
stream argument as with PATHNAME of that stream argument.
For example, the claim that PROBE-FILE should never return NIL when
called on an open stream is pretty clearly wrong. In some
implementations, the file doesn't exist at all until the stream is
closed. I believe the semantics of PROBE-FILE on a stream should in
fact be the same as PROBE-FILE on PATHNAME of that stream, but maybe
we shouldn't guarantee that.
Calling TRUENAME on a stream open for output is also highly suspect,
since it is possible that the ultimate name of the file cannot be
predicted, even disregarding possible renamings. (consider version
numbers)
In our implementation, TRUENAME just calls PROBE-FILE and then
complains if the result is NIL. This means that TRUENAME on an open
stream can signal an error. If this violates someone's TRUENAME
invariants, then we should firm up the definition of TRUENAME
somewhat.
Rob
∂23-Oct-87 1134 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PATHNAME-STREAM (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Oct 87 11:34:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 262109; Fri 23-Oct-87 14:35:17 EDT
Date: Fri, 23 Oct 87 14:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871009-140723-1578@Xerox>
Message-ID: <19871023183516.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 9 Oct 87 14:07 PDT
From: Masinter.pa@Xerox.COM
> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?
I think not.
I think you're wrong here. I think the PATHNAME operation should pass
through to the target of a synonym stream, just as the STREAM-ELEMENT-TYPE
operation does.
I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")
I agree with that. The question is precisely what "is open to a file"
means, and I think it includes synonym streams.
If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)?
The former. That's what p.417, which you like, says.
What is the difference between (pathname x) and (parse-namestring x)?
parse-namestring has more features.
What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?
I don't think we can ascribe any particular semantics to files in Common Lisp.
The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant.
Is it "the same" stream if you change the variable that a synonym stream
indirects through? Not clear. I don't buy this argument. I much
prefer the argument that the only definition of synonym streams that I
can find (CLtL p.329) says "Any operations on the new stream ..." and
does not say anything about exceptions. Also earlier on the page the
phrase "synonym streams that pass all operations on" is used. It would
be hard to be more unambiguous than this, although of course no one
knows what "operations" really means exactly.
∂23-Oct-87 1147 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 11:47:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 11:46:21 PDT
Date: 23 Oct 87 11:45 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 6)
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871023-114622-1090@Xerox>
As I promised back in July, here is a revised version of the
STRICT-REDEFINITION option of FUNCTION-TYPE. In this version, I also
added to the Problem Description some of the issues in
EVAL-DEFEATS-LINKER. I left COMPILED-FUNCTION and COMPILED-FUNCTION-P as
subtypes of FUNCTION. I attempted to move "discussion" items into the
body where appropriate, and eliminated them where they duplicated
arguments already in the body of the proposal. I added a proposal to
extend COERCE to allow (COERCE x 'FUNCTION).
As this is a controversial proposal, avoiding controversy is impossible,
and so I have not attempted it. I am vaguely uneasy that some of the
alternatives and considerations discussed at X3J13 were not mentioned
here -- it *was* a lengthy session. Anyone remember better than I any
other points brought up at the time?
!
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Version 6 by Masinter 23-Oct-87, only
STRICT-REDEFINITION
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs the
status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
In addition, the practice that APPLY, FUNCALL and the numerous functions
that take functional arguments (such as MAPC, MAPCAR, FIND-IF) can
potentially do the equivalent of SYMBOL-FUNCTION to go from a symbol to
its functional-value is a serious impediment to program analysis which
require the ability to determine by examining a program which functional
definitions might be accessed from it. For example, "selective linking"
(which would allow a delivery system to include only those parts of the
Common Lisp library actually accessed) is seriously hampered by the
numerous implicit coersions of symbols to functions.
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations
are free to define subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears. Specifically,
it is an error to use the FUNCTION special form on a symbol that denotes
a macro or special form. (Some implementations may choose not to signal
this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the object and fail
only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
7. Extend the definition of COERCE to allow coersion of objects to type
FUNCTION. That is, "Some symbols and lists may be converted to
functions." (COERCE SYMBOL 'FUNCTION) performs SYMBOL-FUNCTION (getting
the top level function definition, the current lexical context is not
relevant), while (COERCE LIST 'FUNCTION) is equivalent to (EVAL
`(FUNCTION ,LIST)), i.e., it creates a function from a LAMBDA expression
by interpreting it as a list in the top level lexical environment.
8. Modify the description of the macro expansion process to say that
the value of *MACROEXPAND-HOOK* is coerced to a function before being
called as the expansion interface hook by MACROEXPAND-1.
Rationale:
This proposal provides a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
It also enhances the semantics of Common Lisp functional arguments to be
more consistent with other programming languages, and allows better
program analysis tools.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in this proposals,
however, although it corresponds more closely to Scheme and to the work
of the EuLisp community.
Adoption Cost:
Bringing type predicates (FUNCTIONP, etc.) into compliance should
require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified to deal
with functions that are not lists (but from which the list form can be
easily reconstructed if necessary).
Implementations may choose to convert FUNCALL and APPLY to the new
stricter form, but they are not required to do so. Since the use of a
symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.
This proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee.
This proposal allows for better program analysis tools, enhances the
ability to do "selective linking" correctly. It makes it possible to
reduce the total size of a delivered application program. Only those
Common Lisp functions that are actually called need to be
included; implicit coersions tend to create loopholes through which
*every* function might be called.
Conversion cost:
This proposal may have a high conversion cost for some existing Common
Lisp programs. The changes to FUNCTIONP and the FUNCTION type
declaration is relatively easy to deal with. However, the strict
redefinition of FUNCALL, APPLY and functional arguments will require the
addition of an explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all.
Some implementations might provide tools to assist in detecting implicit
coersion of symbols to functions. For example, an implementation might
add run-time test in which the implementation still does the coercion
but that issues a warning message whenever the coercion is actually
needed. Alternatively, a "smart" code-walker or editor macro might find
all of the calls to FUNCALL, APPLY, and the 61 Common Lisp functions
that take :TEST or :KEY arguments and, if the argument is not already an
explicitly quoted FUNCTION form, wrap a COERCE around the body.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code depends on this behavior and would have to be modified if this
proposal is adopted; doing so will be difficult as these uses cannot
easily be detected from simple examination of the program. (Such code is
not currently portable because many existing Common Lisp implementations
already violate these assumptions. CLtL does not clearly state what
values SETF of SYMBOL-FUNCTION will accept and how that object may be
modified.)
Aesthetics:
Making the concept of a function well-defined is a simplification of the
language. This proposal is the cleanest of the alternatives; it defines
a FUNCTION data type and then requires every object used as a function
to be a FUNCTION. While many argue that removing automatic coersion
results in a simpler, cleaner, and more aesthetic language definition,
others have argued otherwise ("its all a matter of taste.")
Discussion:
This proposal has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be revised. (There was one suggestion to create a new type name and
to leave FUNCTION alone, but it was not generally percieved as
acceptable.) The cleanup of the type hierarchy is important to the CLOS
group.
There is much more disagreement about disallowing implicit coercions;
cleanup of implicit coercions are important for compatibility with other
Lisp standards work.
Some argue that it seems better to make this effort once than to live
forever with runtime coercion of functional arguments and the resulting
complexity.
Some have argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
If coercing was continued to be allowed, Common Lisp might need an
APPLICABLE-P predicate that is true of any object that is legal as a
functional argument to APPLY and FUNCALL, since FUNCTIONP would no
longer do this job.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
This proposal interacts with the proposal on compiler semantics: some
claim that strict-redefinition would allow further compiler
optimizations, since compiled FUNCALL is not required to go through
extensive inline checks.
Fahlman, Gabriel and Masinter support FUNCTION-TYPE:STRICT-REDEFINITION.
Pitman and Moon have expressed support for an alternative proposal which
would continue to allow coercion.
∂23-Oct-87 1153 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 11:53:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 11:52:13 PDT
Date: 23 Oct 87 11:51 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: FUNCTION-TYPE (Version 6)
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871023-115213-1106@Xerox>
(I fixed a couple of minor typo's, and cc'd Clinger in this message.)
As I promised back in July, here is a revised version of the
STRICT-REDEFINITION option of FUNCTION-TYPE. In this version, I also
added to the Problem Description some of the issues in
EVAL-DEFEATS-LINKER. I left COMPILED-FUNCTION and COMPILED-FUNCTION-P as
subtypes of FUNCTION. I attempted to move "discussion" items into the
body where appropriate, and eliminated them where they duplicated
arguments already in the body of the proposal. I added a proposal to
extend COERCE to allow (COERCE x 'FUNCTION).
As this is a controversial proposal, avoiding controversy is impossible,
and so I have not attempted it. I am vaguely uneasy that some of the
alternatives and considerations discussed at X3J13 were not mentioned
here -- it *was* a lengthy session. Anyone remember better than I any
other points brought up at the time?
!
Issue: FUNCTION-TYPE
References: functions (p. 32), types (p. 33), FUNCTIONP (p. 76),
SYMBOL-FUNCTION (p. 90), APPLY (p. 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Version 6 by Masinter 23-Oct-87, only
STRICT-REDEFINITION
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs the
status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
In addition, the practice that APPLY, FUNCALL and the numerous functions
that take functional arguments (such as MAPC, MAPCAR, FIND-IF) can
potentially do the equivalent of SYMBOL-FUNCTION to go from a symbol to
its functional-value is a serious impediment to program analysis which
require the ability to determine by examining a program which functional
definitions might be accessed from it. For example, "selective linking"
(which would allow a delivery system to include only those parts of the
Common Lisp library actually accessed) is seriously hampered by the
numerous implicit coercions of symbols to functions.
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations
are free to define subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears. Specifically,
it is an error to use the FUNCTION special form on a symbol that denotes
a macro or special form. (Some implementations may choose not to signal
this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the object and fail
only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
7. Extend the definition of COERCE to allow coercion of objects to type
FUNCTION. That is, "Some symbols and lists may be converted to
functions." (COERCE SYMBOL 'FUNCTION) performs SYMBOL-FUNCTION (getting
the top level function definition, the current lexical context is not
relevant), while (COERCE LIST 'FUNCTION) is equivalent to (EVAL
`(FUNCTION ,LIST)), i.e., it creates a function from a LAMBDA expression
by interpreting it as a list in the top level lexical environment.
8. Modify the description of the macro expansion process to say that
the value of *MACROEXPAND-HOOK* is coerced to a function before being
called as the expansion interface hook by MACROEXPAND-1.
Rationale:
This proposal provides a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
It also enhances the semantics of Common Lisp functional arguments to be
more consistent with other programming languages, and allows better
program analysis tools.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in this proposal,
however, although it corresponds more closely to Scheme and to the work
of the EuLisp community.
Adoption Cost:
Bringing type predicates (FUNCTIONP, etc.) into compliance should
require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified to deal
with functions that are not lists (but from which the list form can be
easily reconstructed if necessary).
Implementations may choose to convert FUNCALL and APPLY to the new
stricter form, but they are not required to do so. Since the use of a
symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.
This proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee.
This proposal allows for better program analysis tools, enhances the
ability to do "selective linking" correctly. It makes it possible to
reduce the total size of a delivered application program. Only those
Common Lisp functions that are actually called need to be
included; implicit coercions tend to create loopholes through which
*every* function might be called.
Conversion cost:
This proposal may have a high conversion cost for some existing Common
Lisp programs. The changes to FUNCTIONP and the FUNCTION type
declaration is relatively easy to deal with. However, the strict
redefinition of FUNCALL, APPLY and functional arguments will require the
addition of an explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might
add run-time test in which the implementation still does the coercion
but that issues a warning message whenever the coercion is actually
needed. Alternatively, a "smart" code-walker or editor macro might find
all of the calls to FUNCALL, APPLY, and the 61 Common Lisp functions
that take :TEST or :KEY arguments and, if the argument is not already an
explicitly quoted FUNCTION form, wrap a COERCE around the body.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code depends on this behavior and would have to be modified if this
proposal is adopted; doing so will be difficult as these uses cannot
easily be detected from simple examination of the program. (Such code is
not currently portable because many existing Common Lisp implementations
already violate these assumptions. CLtL does not clearly state what
values SETF of SYMBOL-FUNCTION will accept and how that object may be
modified.)
Aesthetics:
Making the concept of a function well-defined is a simplification of the
language. This proposal is the cleanest of the alternatives; it defines
a FUNCTION data type and then requires every object used as a function
to be a FUNCTION. While many argue that removing automatic coercion
results in a simpler, cleaner, and more aesthetic language definition,
others have argued otherwise ("its all a matter of taste.")
Discussion:
This proposal has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be revised. (There was one suggestion to create a new type name and
to leave FUNCTION alone, but it was not generally perceived as
acceptable.) The cleanup of the type hierarchy is important to the CLOS
group.
There is much more disagreement about disallowing implicit coercions;
cleanup of implicit coercions are important for compatibility with other
Lisp standards work.
Some argue that it seems better to make this effort once than to live
forever with runtime coercion of functional arguments and the resulting
complexity.
Some have argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
If coercing was continued to be allowed, Common Lisp might need an
APPLICABLE-P predicate that is true of any object that is legal as a
functional argument to APPLY and FUNCALL, since FUNCTIONP would no
longer do this job.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
This proposal interacts with the proposal on compiler semantics: some
claim that strict-redefinition would allow further compiler
optimizations, since compiled FUNCALL is not required to go through
extensive inline checks.
Fahlman, Gabriel and Masinter support FUNCTION-TYPE:STRICT-REDEFINITION.
Pitman and Moon have expressed support for an alternative proposal which
would continue to allow coercion.
∂23-Oct-87 1201 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Oct 87 12:01:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 262138; Fri 23-Oct-87 15:00:31 EDT
Date: Fri, 23 Oct 87 15:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 5)
To: Ram@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12344817269.BABYL@>
Message-ID: <19871023190032.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 Oct 1987 13:46 EDT
From: Ram@C.CS.CMU.EDU
Date: Friday, 23 October 1987 12:52-EDT
From: Masinter.pa at Xerox.COM
[...] I enhanced the discussion section, and added a reference to
p. 417 "the name returned represents the name used to open the
file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
Sounds like XCL is wrong here, although the whole file system interface
chapter is so fuzzy that it's hard to say for sure that anything is wrong.
I think that this should be read as a warning that PATHNAME on an open
stream doesn't necessarily return the truename of the file ultimately
written, or even necessarily the truename of any file that ever
existed or will exist.
Agreed. It seems clear that PATHNAME on an open stream returns something
that resembles the pathname argument that was given when the stream was
opened. I say "resembles" because of defaulting of unspecified fields
in the original argument.
If this is read as a strict requirement, then it is pretty clearly
wrong, since presumably if you do a RENAME-FILE on the stream, you want
PATHNAME of that stream to return the new name, rather than the name
it was originally opened with.
Probably. That's what we do.
If you are trying to clean up the rot with streams as pathnames, you
should carefully look over section 23.3 pp 423-425, as many of these
functions are suggested to do something semantically different with a
stream argument as with PATHNAME of that stream argument.
I think I said that too, in my original comments on this issue.
For example, the claim that PROBE-FILE should never return NIL when
called on an open stream is pretty clearly wrong. In some
implementations, the file doesn't exist at all until the stream is
closed. I believe the semantics of PROBE-FILE on a stream should in
fact be the same as PROBE-FILE on PATHNAME of that stream, but maybe
we shouldn't guarantee that.
Calling TRUENAME on a stream open for output is also highly suspect,
since it is possible that the ultimate name of the file cannot be
predicted, even disregarding possible renamings. (consider version
numbers)
In our implementation, TRUENAME just calls PROBE-FILE and then
complains if the result is NIL. This means that TRUENAME on an open
stream can signal an error. If this violates someone's TRUENAME
invariants, then we should firm up the definition of TRUENAME
somewhat.
It's very difficult to come up with crisp semantics that are implementable
on all file systems. I think for PROBE-FILE and TRUENAME on an open
stream, we can either allow returning NIL / signalling an error, or we
can say that if the file doesn't exist yet (on output) / any more (on input),
these functions are supposed to return their best estimate of what the
file name will be / used to be, which might involve a version number of
:newest. I think the latter is what Symbolics does, since it tends to
make more things work on more file systems.
∂23-Oct-87 1205 Masinter.pa@Xerox.COM Re: Issue: PATHNAME-STREAM (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 12:04:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 12:02:05 PDT
Date: 23 Oct 87 12:01 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 23 Oct 87 14:35 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871023-120205-1123@Xerox>
I'm happy to go along with allowing PATHNAME coersion to traverse
synonym streams; I don't really care as long as it is defined what it
does.
Any other opinions?
∂23-Oct-87 1219 @Score.Stanford.EDU:dcm%hpfclp@hplabs.HP.COM Re: Issue: FUNCTION-TYPE (Version 6)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 12:19:03 PDT
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Fri 23 Oct 87 12:12:59-PDT
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Fri, 23 Oct 87 12:18:28 PDT
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Fri, 23 Oct 87 13:07:24 mdt
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Fri, 23 Oct 87 13:07:00 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Fri, 23 Oct 87 13:07:14 mdt
Return-Path: <dcm@hpfcdcm>
To: CL-CLEANUP@SAIL.STANFORD.EDU
Cc: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 6)
X-Mailer: mh6.5
In-Reply-To: Your message of 23 Oct 87 11:45:00 -0700.
<871023-114622-1090@Xerox>
Date: Fri, 23 Oct 87 13:07:08 MST
Message-Id: <1367.562014428@hpfcdcm>
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
I support FUNCTION-TYPE:STRICT-REDEFINITION.
Dave Matthews
∂23-Oct-87 1359 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 12)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 13:59:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 13:54:33 PDT
Date: 23 Oct 87 13:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 12)
To: cl-cleanup@Sail.stanford.edu
Line-fold: 80
Message-ID: <871023-135433-1351@Xerox>
Include related issues in References section. Changed "proposal" section
to make explicit that these are changes for a new specification document
rather than changes to CLtL.
!
Format for proposals to the cleanup committee (Version 12)
October 23, 1987
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being
discussed, and other references, including other related issues.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL. If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details. Avoid arguing for the proposal here, just describe
it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the
issue. The code should stand alone, and preferably be suitable for
incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is
listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<
∂23-Oct-87 1411 Masinter.pa@Xerox.COM registry of *features* names
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 14:11:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 14:01:49 PDT
Date: 23 Oct 87 14:01 PDT
From: Masinter.pa@Xerox.COM
Subject: registry of *features* names
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871023-140149-1365@Xerox>
I got no response on this message before. Perhaps we could bring the issue up again?
----- Begin Forwarded Messages -----
Date: 11 Jun 87 15:43 PDT
From: Masinter.pa
Subject: Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
to: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-154514-183@Xerox>
At an earlier meeting, there was some discussion over registering the
list of "public" features and "system" packages so that different
implementations would not step over each other in their use of them.
(For example, Xerox uses XCL:, as did one of the X-in-Common-Lisp
modules. User code that explicitly referenced XCL:DRAW would have to be
edited explicitly.)
This seems actually to get more at the heart of the matter than the
current proposals for #+- and the like.
Perhaps we could discuss this at our meeting?
∂23-Oct-87 1436 Gregor.pa@Xerox.COM SETF-FUNCTION-VS-MACRO (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 14:36:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 OCT 87 14:30:35 PDT
Date: Fri, 23 Oct 87 14:30 PDT
From: Gregor.pa@Xerox.COM
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Scott E.
Fahlman <Fahlman@C.CS.CMU.EDU>, Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19871015211100.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<FAHLMAN.12342792040.BABYL@C.CS.CMU.EDU>,
<19871016003933.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<FAHLMAN.12342796585.BABYL@C.CS.CMU.EDU>,
<19871023013955.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<871022-175359-5842@Xerox>
Message-ID: <871023143012.1.GREGOR@SPIFF.isl.parc.xerox.com>
Line-fold: no
Date: Thu, 15 Oct 87 17:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
First let me say that I am a very strong supporter of this proposal.
Moon and I actually worked on it a fair amount before he wrote it up, I
think it would be a significant improvement to the language.
In particular, I would like it to be the case that however we finally
write this up, we make it clear that in many cases (not all cases)
defsetf is now obsolete. I believe that having programs which don't
need to use defsetf avoid doing so will considerably simplify the Common
Lisp evaluator as seen by those programmers. I believe that teaching
the style of SETF which doesn't use defsetf (long) before the style
which does will make it more understandable to students.
Date: Thu, 15 Oct 87 20:21 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO). This seems like a more radical change than is really necessary to
accomplish the stated purposes. It is a considerable extension to the
idea of a "function name", at least for standard Common Lisp
implementations that do not implement Lisp machine style
function-specs.
Of course another solution to this problem would be to say that the
function name for the "setf function" for FOO is |SETF FOO|.
Specifically, instead of having the mapping:
package::foo ==> (setf package::foo)
package::foo ==> package::|SETF FOO|
Of course |bar| would become |SETF bar|.
The advantage of this is it doesn't require introducing list function
specs.
If we do introduce list function specs, we have to decide wether they
can appear as the car of a form (I assume they can't).
-------
∂23-Oct-87 1514 Moon@STONY-BROOK.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Oct 87 15:14:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 262399; Fri 23-Oct-87 18:14:18 EDT
Date: Fri, 23 Oct 87 18:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: Gregor.pa@Xerox.COM
cc: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <871023143012.1.GREGOR@SPIFF.isl.parc.xerox.com>
Message-ID: <19871023221404.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Fri, 23 Oct 87 14:30 PDT
From: Gregor.pa@Xerox.COM
In particular, I would like it to be the case that however we finally
write this up, we make it clear that in many cases (not all cases)
defsetf is now obsolete. I believe that having programs which don't
need to use defsetf avoid doing so will considerably simplify the Common
Lisp evaluator as seen by those programmers. I believe that teaching
the style of SETF which doesn't use defsetf (long) before the style
which does will make it more understandable to students.
I agree with this, but I think "obsolete" might be too strong a word.
What we're saying is that using setf functions instead of setf macros
wherever you can is good programming style. I think the analogy to regular
macros is compelling. In the old days people used to over-use macros,
or even worse fsubrs, where they could just as well have used functions;
eventually it was widely realized that this was a bad idea, and that
macros should only be used where you are actually trying to do syntax
extensions. This didn't mean macros were obsolete, it just meant that
people better understood when it was good programming style to use them.
In the CL-Cleanup proposal form, this would go in the Benefits section.
Date: Thu, 15 Oct 87 20:21 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO).
Of course another solution to this problem would be to say that the
function name for the "setf function" for FOO is |SETF FOO|.
Specifically, instead of having the mapping:
package::foo ==> (setf package::foo)
package::foo ==> package::|SETF FOO|
Of course |bar| would become |SETF bar|.
The advantage of this is it doesn't require introducing list function
specs.
Right. The problem is that "package::" above hides a multitude of
sins. How is (defun (setf car) (new-car cons) (rplaca cons new-car) new-car)
to be written in your proposal? There is a separate symbol |SETF CAR|
in every package, unless this (and all possible others) is pre-interned
in the Lisp package. I think what this shows is that if we want to derive
one object from another object, in Lisp doing this with list processing
works a whole lot better than doing it with string processing.
It might be worth putting this little digression into the Discussion section.
If we do introduce list function specs, we have to decide wether they
can appear as the car of a form (I assume they can't).
The latest version states that they can't.
∂23-Oct-87 1526 Masinter.pa@Xerox.COM Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 15:26:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 15:23:08 PDT
Date: 23 Oct 87 15:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871023-152308-1515@Xerox>
This is not for release. I think I tend to agree with Scott that I'd
rather see a little more shuffling in GETF and LDB and less in SETF of
symbols. Hopefully, SETF-FUNCTION-VS-MACRO would reduce the amount of
hair that was involved for users of setf, anyway.
!
Issue: SETF-METHOD-FOR-SYMBOLS
References: CLtL pp. 105, 99. Issue: PUSH-EVALUATION-ORDER.
Category: CHANGE
Edit history: Version 1 Moon 21 Sep 87
Version 2 Masinter 23-Oct-87
Problem description:
The description of SETF in CLtL is inconsistent in that page 99
requires side-effects to be elaborated in left-to-right order,
while page 105 specifies a setf-method for symbols that makes
it impossible to implement this in some cases, such as the test
case given below (provided by Timothy Daly of IBM).
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the example of the result of
(GET-SETF-METHOD 'FOO) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
to return, for example,
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
Test Case:
Test Case (A): Given
(LET* ((R (LIST 'A 1 'B 2 'C 3))
(S R))
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
If side-effects are elaborated in left-to-right order,
the setq of R to NIL should not affect the result, since
it occurs after R is read and before R is written, and
therefore the value of both R and S should be (A 1 B 6 C 3).
A typical result in an implementation that believes CLtL p.105
more than CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).
Test Case B:
(LET((A 0))
(INCF (LDB (BYTE 2 2) A) (SETQ A 2))
A)
Does this return 8, 10, or 2? If p. 99's description of order of
evaluation is correct, this should return 8.
Rationale:
The general principle mentioned on p.99 should override the
specific example on p.105. The latter is probably just a mistake.
Current practice:
Symbolics and Lucid return the incorrect result mentioned in the test
case A. (Symbolics plans to fix this in the next release.) Franz and
Xerox returns something else: R = nil and S = (a 1 b 6 c 3). HP Common
Lisp produces the recommended value. Xerox Common Lisp returns A=10 in
Test Case B.
Spice Lisp returns the recommended value for the test case A, even
though it uses the suggested value for the setf-method for symbols,
because the get-setf-method for GETF introduces additional temporary
bindings.
Adoption Cost:
SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some
care might be required in updating implementations. However, in
some implementations changing what get-setf-method returns when its
argument is a symbol is the only change required.
It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.
Cost of non-adoption:
Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.
Benefits:
Improved portability of Common Lisp programs.
Conversion Cost:
This change is incompatible because it changes the result of some forms
that are not erroneous. However, it's unlikely that very many users are
intentionally depending on the current behavior. In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.
Esthetics:
See "cost of non-adoption".
Discussion:
I wish CLtL did a much better job of explaining the philosophy of SETF,
and included some better examples of precisely what is meant by the
"`obvious' semantics" mentioned on page 99. I will accept some of the
blame for this lack in the documentation. --Moon
This proposal is consistent with PUSH-EVALUATION-ORDER:ITEM in affirming
the left-right order of evaluation of subforms of generalized variable
access forms.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
The discussion seemed to be moving toward considering an alternative,
which is to require the setf method for GETF and LDB to bind temporary
values, e.g.,
"When it comes to efficiency, I'd rather have a little extra variable
shuffling in Getf and places like that than in all setf's involving a
symbol destination."
(define-setf-method getf (place prop &optional default &environment env)
(multiple-value-bind (temps values stores set get)
(get-setf-method place env)
(let ((newval (gensym))
(ptemp (gensym))
(def-temp (gensym)))
(values `(,@temps ,(car stores) ,ptemp ,@(if default
`(,def-temp)))
`(,@values ,get ,prop ,@(if default `(,default)))
`(,newval)
`(progn (setq ,(car stores)
(%primitive putf ,(car stores) ,ptemp ,newval))
,set
,newval)
`(getf ,(car stores) ,ptemp ,@(if default `(,def-temp)))))))
∂23-Oct-87 1635 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 16:35:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 16:32:35 PDT
Date: 23 Oct 87 16:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 3)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871023-163235-1628@Xerox>
This hasn't been discussed since last June. Has anyone any further
thoughts? I moved some of the discussion around in this version, and
summarized some of the banter in the previous mail. I made the proposal
more explicit by mentioning all of the affected functions.
Since CLtL is fairly specific about "filename ... may be a stream, a
pathname, or a string" I said merely to reiterate it in this proposal.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426)
Cleanup issue PATHNAME-STREAM
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Category: (Incompatible) CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically,
PATHNAME, TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST,
PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE,
PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING,
HOST-NAMESTRING, ENOUGH-NAMESTRING are changed to not allow symbols
for their pathname argument.
Reiterate that (as implied by their respective descriptions in CLtL)
OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE, DELETE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its
pathname argument.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in
MacLisp (which did not have strings) and causes much error-prone
behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since
this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that
check the type of this argument, program error checking will be
improved. In dealing with case-sensitive file systems, users won't do
(load 'foo) and wonder why file "FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is
erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find
a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file
named
"NIL" on some perhaps unexpected directory.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings. For example,
some users are used to type interactively (LOAD 'FOO) to mean (LOAD
"FOO"). This is not explicitly allowed in CLtL, so such behavior has not
been portable.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error
because it accepted symbols.
The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a
symbol
here was that it did not have strings at all. However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
"If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive."
- Eric Benson
"Note that an explicit decision was made early in the design of CL
not to make all coercions transitive. For example, symbols
coerce to strings (for string functions), and strings are sequences
(and so can be mixed with other sequence types), but symbols are
not sequences.
If we cannot have consistency, let us then have consistency of
inconsistency. (Also known as, "This screw-up was good enough
for grampa, and it's good enough for me!")
-- Guy Steele
∂23-Oct-87 1700 Masinter.pa@Xerox.COM Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 17:00:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 17:01:17 PDT
Date: 23 Oct 87 17:01 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
In-reply-to: peck@Sun.COM's message of Fri, 23 Oct 87 13:56:40 -0700
To: peck@Sun.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <871023-170117-1668@Xerox>
Version 3 will change
>> The phase "subforms of the reference" which appears several times in
>> CLtL should be made more specific to be "subforms of the
>> [generalized-variable manipulating macro] arguments".
to
>> The phase "subforms of the reference" which appears several times in
>> CLtL should be made more specific to be "arguments of the
>> [generalized-variable manipulating] macro".
We like to get it right in the proposals.
∂23-Oct-87 1716 Masinter.pa@Xerox.COM Environment-arguments, MACRO-FUNCTION-ENVIRONMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 17:16:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 17:17:25 PDT
Date: 23 Oct 87 17:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Environment-arguments, MACRO-FUNCTION-ENVIRONMENT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 23 Oct 87 17:58 EDT
To: Common-Lisp-Object-System@sail.stanford.edu
cc: CL-Cleanup@Sail.stanford.edu
Message-ID: <871023-171725-1686@Xerox>
Moon (on CLOS list):
"We need to note somewhere that SYMBOL-FUNCTION, FBOUNDP, and
FMAKUNBOUND take an optional environment argument, just like
ENSURE-GENERIC-FUNCTION, SYMBOL-CLASS, CBOUNDP, and CMAKUNBOUND.
This is necessary to be able to find a generic function object,
given its name, in the compile environment. FMAKUNBOUND may
be just for consistency, but FBOUNDP and SYMBOL-FUNCTION are to
allow ENSURE-GENERIC-FUNCTION to work."
Related issues were discussed at some length on CL-CLEANUP. If someone
wants to write this up for cleanup, I have a file of the discussion
(under GET-SETF-METHOD-ENVIRONMENT in Jan-87 and ENVIRONMENT-ARGUMENTS
in April 87).
There seems to be a number of separable issues, but separating them is
difficult. Volunteers appreciated.
∂23-Oct-87 1728 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 87 17:28:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 87 17:29:18 PDT
Date: 23 Oct 87 17:29 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
cc: Masinter.pa@Xerox.COM
Message-ID: <871023-172918-1711@Xerox>
I attempted to make the change from "keyword" to Named-argument in this
version.
This issue was conditionally passed at the last X3J13 pending only the
terminology change.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as argument names in
&key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the names of named argument; allow
any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a named argument that is not a keyword symbol is to use the (indicator
variable) syntax in the function's lambda list. The keyword-indicator
can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
named arguments to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be keywords.
The desire for non-keyword named arguments arises when the set of named
arguments accepted by a function is the union of the sets of named
arguments accepted by several other functions, rather than being
enumerated in a single place. In this case, it becomes desirable to use
packages to prevent accidental name clashes among named argument of
different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept named arguments and
pass them on to one or more applicable methods, with each method
defining its own set of arguments that it is interested in. If this
proposal is not adopted, either the named arguments will be required to
be keywords, which will require the methods to have non-modular
knowledge of each other in order to avoid name clashes, or the methods
will have to be defined with an ad hoc mechanism that duplicates the
essential functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary named arguments from
the caller and passes those arguments along to an internal routine using
named arguments of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some named argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between keyword, indicating a symbol in
the KEYWORD package, and named arguments. It is likely that this is best
served by changing those instances of "keyword" to "named argument" when
the specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂23-Oct-87 1748 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Oct 87 17:48:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 262518; Fri 23-Oct-87 20:48:44 EDT
Date: Fri, 23 Oct 87 20:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <871023-172918-1711@Xerox>
Message-ID: <19871024004826.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Oct 87 17:29 PDT
From: Masinter.pa@Xerox.COM
I attempted to make the change from "keyword" to Named-argument in this
version.
I no longer believe in that terminology, having tried it for a while in the
CLOS world. I think keeping the CLtL terminology of "keyword arguments"
and "keyword names", with a disclaimer that keyword symbols, lambda-list
keywords, and keyword arguments are three different things, works out better
on the whole.
∂24-Oct-87 1730 Masinter.pa@Xerox.COM Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Oct 87 17:30:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 OCT 87 17:31:13 PDT
Date: 24 Oct 87 17:30 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Line-fold: 80
cc: Masinter.pa@Xerox.COM
Message-ID: <871024-173113-2262@Xerox>
My habit of starting alphabetically and not getting all the way done has
caused this issue to be neglected. I thought I would start from the end
this pass. This is an important issue, it seems to be in the way of
producing a valid portable error system.
It took me several hours to try to put together a version that
summarized the arguments that took place last May. I hope I have
captured them.
We now also have some new members; do we have any new opinions? (If
anyone wants my archive on this or any issue, let me know and I will
store it.)
!
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
References: UNWIND-PROTECT (p140, p142, p39)
Issue IGNORE-ERRORS, Draft error proposal.
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 27-Feb-87
Version 2 by Masinter 24-Oct-87
Problem Description:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
Situation 0. Transfer to another point within the cleanup form.
(UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX))
There is no ambiguity about how this form is to be interpreted.
Effectively:
. 3 evaluates to itself, which is queued for return
from the UNWIND-PROTECT.
. The BLOCK expression is entered, 4 is returned to
it and discarded because this is a not-for-value
situation.
. XXX is printed, XXX is returned by the PRINT and
that value is discarded because this is a not-for-value
situation.
. The 3 which was yielded earlier is retrieved and
returned as the value of the UNWIND-PROTECT.
Situation 1. Transfer to a point inside the point to which control
would have transferred.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found within the scope of the target of the
pending THROW (to FOO).
Situation 2. Transfer to a point outside the point to which return would
already have been. For example:
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW (to FOO).
What is the appropriate behavior for situation 1 and situation 2 and
similar ones? For example, suppose that when WITH-OPEN-FILE tries to
close the file upon unwinding, it signals an error, and the condition
handler also attempts to throw? The question applies to all non-local
transfers, whether performed by THROW, RETURN-FROM, RETURN, GO.
There is general agreement about Situation 2, but three proposals for
Situation 1.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:2-EXIT):
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.)
In Situation 2, the value 4 is returned from the (CATCH 'BAR ...); XXX
is not printed.
[In no case will UNWIND-PROTECT cleanup forms ever be attempted more
than once.]
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1-RETURN-INNER):
While processing UNWIND-PROTECT cleanup forms, a non-local exit to a
point outside of the scope of the UNWIND-PROTECT, but still within the
dynamic scope of of the target of the original non-local exit....
... the second non-local exit succeeds, and the original pending exit is
discarded.
In Situation 1, the pending seek for tag FOO is discarded by the second
THROW to BAR and the value 4 is transfered to (CATCH 'BAR ...), which
returns 4. The (CATCH 'FOO ...) then returns the 4 because its first
argument has returned normally. XXX is not printed.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1-RETURN-OUTER):
... the second non-local exit instead continues the original (more
extensive) one. In Situation 1, the second THROW to BAR is discarded in
lieu of continuing the THROW to FOO.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1-SIGNAL-ERROR):
... signals an error.
(If the IGNORE-ERRORS cleanup proposal or the proposed error/signal
system be adopted, it would be an error which would not be ignored by
IGNORE-ERRORS, for reasons outlined below.)
In situation 1, the second THROW to BAR would signal an error.
Implementation notes:
There are several ways of implementing 1-SIGNAL-ERROR; this example is
merely given to illustrate:
1. Every CATCH, and every TAGBODY and BLOCK which might have non-local
exits via GO, RETURN or RETURN-FROM creates a marker with a validity
state, initially true.
2. When a non-local exit (via THROW, GO, RETURN or RETURN-FROM) plans to
return control past a validity marker, it sets its validity state to
false, before any state is removed from the stack and any cleanup form
is evaluated. (For THROW, this happens after the target CATCH is found,
since, if there is no matching catch, the error is signalled in the
dynamic environment of the THROW).
3. If the validity state of the target of a non-local exit is false, an
(non-ignorable) error is signalled.
4. When a non-local exit evaluates an unwind-protect cleanup form, it
first removes it from the list of such forms, so that with any
subsequent non-local exit it won't be evaluated again.
Rationale:
Current Practice:
Some implementations generate garbage code in situations 2 and 3. Some
have differing behavior compiled and interpreted.
Most that have implementations seem to implement 2-EXIT, but there is
some divergence in Situation 1. For example, Spice Lisp and Xerox
implement 1-RETURN-INNER, while Symbolics implements 1-SIGNAL-ERROR.
Some compiled implementations agree with 1C and 2C. Some just output
garbage code (probably because lots of people don't anticipate this
case, which is admittedly quite rare).
Adoption Cost:
While require some compiler modifications in some implementations. In
some cases, that work was in order anyway since compilers may currently
be doing nothing particularly useful or defensible with the code in
question. There is some sentiment that 1-RETURN-INNER is the simplest
to implement.
Benefits:
No matter which proposal is adopted, having this situation uniformly
treated seems critical.
Programs which do this accidentally should behave the same on all
systems so that bugs can be detected and fixed very early rather than
being found later on a system which disagrees.
Programs which do this on purpose generally are trying to do something
fairly intricate and really need to be able to depend on it being
uniformly treated. A portable error/signal system and debugger may be
among these.
1-RETURN-INNER's motiviation is simplicity and aesthetics;
1-SIGNAL-ERROR and 1-RETURN-OUTER's motivation are robustness and
convenience. These are discussed here.
1-RETURN-INNER is more intuitive to programmers who reason about
programs in terms of continuation passing. It falls out of the normal
scoping rules as a consequence of the fact that the cleaup code is
evaluated in the lexical and dynamic environment in which the
UNWIND-PROTECT form appears. The action of THROW is usefully described
by saying that it is just like any other function. It happens to discard
the current continuation, run some cleanup things (like variable
unbindings and UNWIND-PROTECT actions), and transfer control elsewhere
in the program. In doing so, the function uses data structure primitives
not generally available to other programs, but it is not linguistically
different and receives no special exemption with regard to THROWs or
other non-local transfers of control done within its execution. A THROW
from within an UNWIND-PROTECT cleanup is not different than one in any
other code; it discards the ongoing action (stack unwinding) and
replaces it by another action (as it happens, another stack unwinding).
The previous unwind is never resumed.
1-SIGNAL-ERROR and 1-RETURN-OUTER complicate the language semantics but
improve environment reliability. For example, given
(LOOP
(CATCH 'FOO
(UNWIND-PROTECT (LOOP)
(THROW 'FOO T))))
With 1-RETURN-INNER there is no way of exiting such a form.
1-SIGNAL-ERROR would prevent programmers from getting into this
unfortunate situation.
1-RETURN-OUTER would guarantee that, upon a non-local exit out of a
computation, the computation will be exited, one way or another.
Conversion Cost:
Most user programs don't do this so the cost of converting existing code
is probably minimal. (There is some evidence that there are programs
that expect the behavior of 1-RETURN-INNER, so that the cost of
conversion is even lower in that case.)
Discussion:
1-SIGNAL-ERROR (and 1-RETURN-OUTER) prevent a serious environment bug,
where it is possible to create loops which cannot be aborted with
interrupts, the debugger or the like.
The error signalled in 1-SIGNAL-ERROR must not be one caught by
IGNORE-ERRORS; otherwise
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
would have similar non-termination capabilities.
Some argue that the situation that 1-SIGNAL-ERROR attempts to prevent is
perfectly valid: while it would be for a programmer to get into this,
the user has pretty clearly asked to have a loop that cannot be exited
and deserves to have that request carried out. "We create syntax in a
language not to allow us to say the things that are obvious, but so that
we can say things that are not obvious. If we didn't need to say things
that were not obvious, we'd just jumble all the words together and
assume people would figure out some uniquely determined, obviously
useful interpretation. In fact, we make careful rules to allow us to say
bizarre things not so we can say bizarre things all the time, but so
that if there comes a time to say such things, we won't be at a loss for
words."
One real example offered was a top-level, where the Common Lisp
implementation's abort character would return to that level.
(DEFUN MY-TOPLEVEL ()
(PROG ()
LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL)
(GO LOOP))))
so that people who'd invoked my toplevel couldn't get back to toplevel
Lisp. While it might be rare, it's not unthinkable that someone could
really write this and mean what they said...
Some do not credit the seriousness of the "environment bug"; generally,
programming environments may need some way of aborting such a program
without executing the offending cleanup form, but it is an environment
problem which should have an environment solution. There are many other
ways a malicious Lisp user could blow the system out
of the water, e.g. (makunbound '*terminal-io*), although those are
admittedly not valid Common Lisp programs.
Moon supported 1-SIGNAL-ERROR or 1-RETURN-OUTER.
Fahlman said he is inclined to support 1-SIGNAL-ERROR over
1-RETURN-OUTER.
Masinter, Pitman and Steele indicated support for 1-RETURN-INNER.
All endorse 2-EXIT.
∂24-Oct-87 1752 Masinter.pa@Xerox.COM Issue Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Oct 87 17:52:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 OCT 87 17:53:06 PDT
Date: 24 Oct 87 17:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue Status
to: CL-CLEANUP@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871024-175306-2269@Xerox>
This is my status file as of today. Please give your attention to the
???? issues; if you want to send me one general message covering your
opinion or non-opinion on various messages, I will try to sort it out.
Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
% need volunteer to write up
???? A question: Please reply.
~ Tabled until resubmitted, i.e., no immediate action proposed.
!
* Proposal format (Version 12, 23-Oct-87)
Format for proposals to the cleanup committee.
Version 12 mailed October 23, 1987
???? Ready for release?
ADJUST-ARRAY-DISPLACEMENT (Version 3, 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Need volunteer to revise, clarify :displaced-to ommitted
same as :displaced-to nil.
Not ready for release.
% ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES
file)
(p 297) "Specify that the fill pointer is ignored for the
purposes of deciding whether a given element of a new array
resulting from ADJUST-ARRAY should take its value from the
old array contents or from the specified :INITIAL-ELEMENT."
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1, 22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
APPEND-DOTTED (version 1, 27 Jul 87)
Sumbitted by KMP.
Need mod to Current Practice
Mention (append () t), clarify NCONC?
Not ready for release.
% APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file)
(p 322) At end of second paragraph on *APPLYHOOK*,
clarify that the apply hook function is not used
when special forms are evaluated.
Need volunteer to submit.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?
~ ASSOC-RASSOC-IF-KEY (Version 1, 22 Apr 87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
Not ready for release
* COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
???? Ready for release?
{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Await error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
% CONSTANT-SIDE-EFFECTS (not yet submitted)
(it is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Need volunteer to submit
% DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
* DECLARE-MACROS (version 1, 22-oct-87)
(Allowing macros to expand into declarations is not worth
the ambiguity & implementation cost.)
???? Ready for release?
% DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
Is all of this mechanism necessary?
DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Pavel may propose something here.
{ DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Await object proposal.
{ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Await object proposal.
* DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
(Documentation string is not evaluated.)
Submitted, no replies
???? Ready for release with endorsement?
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
% DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Need volunteer to submit.
DO-SYMBOLS-DUPLICATES (Version 2, 29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
~ EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, deal with #., #, changes
independently.
EXPORT-COORDINATION (no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Not yet formally submitted.
Looking for proposal to make package manipulation lexical.
{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
% FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just an open
file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting
to STRING-CHAR for non-stream arguments and to the element-type of the
stream for a stream argument."
Need volunteer to write up.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?
% FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer to write up.
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
* FUNCTION-TYPE (Version 6, 23-Oct-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
??? STRICT-REDEFINITION ready for release?
% FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
Need volunteer to submit.
% FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace
etc) Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
~ GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
???? Ready for release?
{ IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
{ IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
Awaiting error proposal
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7, 23-Oct-87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
???? Ready for release?
% LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
& LOAD-TIME-EVAL (Version 2, 17-JUL-87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
No discussion after Version 2.
???? ready for release?
% MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
re-extract from environment-arguments?
CLOS notes say they need this?
* OPEN-KEYWORDS-EXISTS (Version 1, 17-Jul-87)
No discussion.
???? Ready for release ?
* PATHNAME-STREAM (Version 5, 23-Oct-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
*must* the pathname be the one supplied to open?
~ PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
Proposal for :SUBDIRECTORY rejected; make :DIRECTORY a structure?
Unlikely to be portable.
* PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
???? Ready for release?
% PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components,
etc in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
~ PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction
must or even ought to work."
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
This got sidetracked. Lets try to hash this one out.
~ PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
* PUSH-EVALUATION-ORDER (Version 2, 23-Oct-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Also INCF, PUSHNEW, etc.
??? Ready for release?
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
discussion Feb 87.
Lets get this one moving...
* REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Does it solve our problems?
??? Ready for release?
SETF-METHOD-FOR-SYMBOL (Version 2, 23-oct-87)
(Change recommendation for (get-setf-method symbol)?)
"Maybe we should fix the definition for setf of ldb rather than
the values returned for symbol?"
Not ready for release.
* SETF-FUNCTION-VS-MACRO (Version 1, 15-Oct-87)
(Allow (DEFUN (SETF FOO) ..))
Discussed at length on CLOS
???? Ready for release with Masinter's edits?
* SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2, 28-Apr-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
No discussion since May-87
???? Release GENERALIZE option?
* SHADOW-ALREADY-PRESENT (Version 2, 27 Aug 87)
Revised according to discussion
???? Ready for release?
{ SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
~ SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 9-Mar-87)
(What package are *features* in?)
Mild support for :KEYWORD
Register *features*?
???? Report out with only :KEYWORD proposal?
% SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
% STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must be
initially bound to synonym streams to *TERMINAL-IO*; demote this to the
level of an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX redirection to win."
Need volunteer to submit
% STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc were
CLOS classes?
{ STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Await CLOS
% SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end of
the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
% TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
TRACE-FUNCTION-ONLY (Version 1, 21-Oct-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2, 24-Oct-87)
(GO out of UNWIND-PROTECT clauses.)
Need decision among 3 proposals.
∂24-Oct-87 1757 Pavel.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Oct 87 17:57:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 24 OCT 87 17:56:02 PDT
Date: Sat, 24 Oct 87 17:55:55 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
In-reply-to: <871024-173113-2262@Xerox>
To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Message-ID: <871024-175602-2272@Xerox>
I support 1-RETURN-INNER because of the semantic cleanliness issue. I
don't give much credit to the unbreakable loop issue; it doesn't seem
like a linguistic issue to me. After all, Common Lisp doesn't even
admit that there is such a thing as an interrupt character.
I also support 2-EXIT.
Pavel
∂25-Oct-87 1331 RAM@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 13:31:42 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 25 Oct 87 16:32:12-EST
Date: Sun, 25 Oct 1987 16:32 EST
Message-ID: <RAM.12345382618.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
In-reply-to: Msg of 24 Oct 1987 20:30-EDT from Masinter.pa at Xerox.COM
I don't see why the "is an error" possibility for case one has been
discarded out of hand. The only argument for making this well defined
is that it is "in the way of producing a valid portable error system".
One could suppose that there are complex, non-obvious, situations in
which one of RETURN-INNER or RETURN-OUTER is required to implement an
error system. If this were the case, then we would be forced to make
that choice. But Moon (I believe) argues that it is quite acceptable
to be required to signal an error, and thus SIGNAL-ERROR is presumably
not incompatible with having a portable error system.
Moon further went on to argue that the error which is required to be
signalled is required not to be handleable.
This seems to be a strong indication that "is an error" is in fact the
correct interpretation. The language semantics of "an error that
cannot be handled" is indistinguishable from "is an error", since a
program cannot exploit this distinction. This is a pure environment
issue.
Of course, saying that this condition "is an error" allows all of the
suggested interpretations, and thus means that noone is required to to
anything.
My presonal preference for a definite semantics of this construct is
RETURN-INNER. This is largely due to the conceptual simplicity that I
as a compiler writer perceive. The reason I have argued for "is an
error" is that I don't want to be forced to implement any of the
alternatives.
I think that people have greatly underestimated the semantic garbage
that this change will load on to lexical exits. The reason that this
doesn't bother anyone is that existing Common Lisp implementations
implement non-local lexical exits on top of dynamic exits, rather than
the other way around. It is bogus to suppose that each syntactically
distinct BLOCK will have a distinct run-time data structure that you
can allocte bits in.
If you have a construct like:
(block foo
...
(block bar
...))
It is not currently required that compilers maintain any distinction
between blocks FOO and BAR; those are just different names for the
same continuation.
Yet if we fill in the ...'s in this way, then SIGNAL-ERROR prevents
the obvious interpretation of BLOCK as naming a continuation:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
FOO and BAR name exactly the same continuation, but they are somehow
magically gratuitously distinctified simply due to being used from
within an unwind-protect.
Note that in this test case, the result of RETURN-INNER and
RETURN-OUTER are exactly the same. Although I favor RETURN-INNER,
RETURN-OUTER is not nearly as semantically bankrupt as SIGNAL-ERROR,
since it doesn't require distinctions to be made between identical
continuations.
But I still believe RETURN-OUTER is more difficult to implement than
RETURN-INNER, since it still introduces an innerness/outerness
distinction that is not fundamentally part of a lexical exit. In
simply naming these proposals RETURN-INNER/RETURN-OUTER, a dynamic
component has implicitly been introduced into lexical exit.
RETURN-INNER simply ways "use this continuation"; RETURN-OUTER says
"maybe use some other continuation depending on some rule of dynamic
scoping that is otherwise totally irrelevant to the semantics of
RETURN-FROM unless there is an UNWIND-PROTECT around somewhere".
Rob
∂25-Oct-87 1350 FAHLMAN@C.CS.CMU.EDU Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 13:50:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 16:51:05-EST
Date: Sun, 25 Oct 1987 16:51 EST
Message-ID: <FAHLMAN.12345386056.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
In-reply-to: Msg of 22 Oct 1987 21:51-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I tend to agree with Moon on this. This proposal is a band-aid in an
area where substantial work is needed. Patching up the pathname stuff
is probably harmless, but doesn't make much sense as long as Provide and
Require themselves are so ill-defined. This mechanism needs serious
work as part of a comprehensive cleanup of compilation-environment and
time-of-evaluation issues.
-- Scott
∂25-Oct-87 1430 FAHLMAN@C.CS.CMU.EDU Issue: TRACE-FUNCTION-ONLY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 14:30:40 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 17:31:07-EST
Date: Sun, 25 Oct 1987 17:31 EST
Message-ID: <FAHLMAN.12345393345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: kempf%hplabsz@HPLABS.HP.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: TRACE-FUNCTION-ONLY
In-reply-to: Msg of 23 Oct 1987 11:25-EDT from kempf%hplabsz at hplabs.HP.COM
> However,
> I think that the :BREAK stuff does not belong here. If you want to
> propose that as a required extension, you should do it in a separate
> proposal and try to provide a better justification than "some
> implementations do this, so I've randomly tossed it in with the other
> stuff".
I've found being able to introduce a break after the printing of tracing
information in our Lisp to be an invaluable debugging tool, as have
other developers here. At the moment, they are beating my door down
for the same capability (along with simple tracing) for individual
methods, in the portable CLOS implementation. I can add this justification
to the proposal.
This doesn't really respond to the objection I raised. I didn't suggest
that :BREAK was not worthwhile. I said that there are two distinct
issues here: whether to extend TRACE to work for methods and setf
functions, and whether to extend trace to do all sorts of other neat
things. The former is probably not controversial, and I could
support a proposal that contains just this.
If you insist upon extending the standard to include :BREAK, we ought to
go all the way and specify exactly what an extended-form trace ought to
handle. In addition to :BREAK, we probably want :BREAK-AFTER, :WHEREIN,
:PRINT, :PRINT-AFTER, and maybe some other things. We want a syntax
that will handle all this, plus function specs, and that still will allow
you to say (TRACE A B C) when you have a bunch of functions you want to
look at in the usual way.
So I oppose the current proposal that includes only :BREAK and that
adopts a more restrictive syntax for TRACE for no good reason.
It might make sense to propose a comprehensive package of TRACE
extensions that we would all follow, though getting agreement at this
late date might take some negotiation among the N divergent
implementations.
While we're discussing this issue, another part of the proposal was to
include a generic function, called TRACE-EXECUTION, which took as an
argument an object representing an executable entity, like a method object,
generic function, function, symbol, etc. An implementation specific method
would run to arrange for tracing code to be inserted. Similar to
PRINT-OBJECT, all implementations would have to implement tracing using
this generic function. The advantage of this is that if someone extends
CLOS/CL by including a new funcallable object, like, for example, a
remote procedure call, debugging becomes extensible as well.
This is going to be a fairly hairy proposal, I think, since you have to
trace function names and not functions (unless you want to force
implementors to do surgery on compiled function objects). I'd be
interested in seeing the details of this proposal.
-- Scott
∂25-Oct-87 1502 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 15:02:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 18:02:38-EST
Date: Sun, 25 Oct 1987 18:02 EST
Message-ID: <FAHLMAN.12345399085.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-CLEANUP@SAIL.STANFORD.EDU
Cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: FUNCTION-TYPE (Version 6)
In-reply-to: Msg of 23 Oct 1987 14:51-EDT from Masinter.pa at Xerox.COM
I (still) support FUNCTION-TYPE: STRICT-REDEFINITION.
A couple of minor comments on this presentation:
There needs to be a heading, "Rationale", I think, after point 8 of the
proposal proper. You want to clearly mark the transition from proposal
to argument.
I still don't subscribe to Clinger's view of selective linking, but the
comments in this proposal do no harm.
Now that there is no discussion of a coercing version of the proposal,
some of the material in the discussion section has dangling pointers.
To fix this, just say at the start of the discussion section that one
option discussed earlier was similar to this one, but allowed FUNCALL,
etc. to take anything that can be coerced to a function.
-- Scott
∂25-Oct-87 1639 FAHLMAN@C.CS.CMU.EDU registry of *features* names
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 16:39:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 19:40:14-EST
Date: Sun, 25 Oct 1987 19:40 EST
Message-ID: <FAHLMAN.12345416850.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: registry of *features* names
In-reply-to: Msg of 23 Oct 1987 17:01-EDT from Masinter.pa at Xerox.COM
At an earlier meeting, there was some discussion over registering the
list of "public" features and "system" packages so that different
implementations would not step over each other in their use of them.
(For example, Xerox uses XCL:, as did one of the X-in-Common-Lisp
modules. User code that explicitly referenced XCL:DRAW would have to be
edited explicitly.)
...
Perhaps we could discuss this at our meeting?
Since I won't be able to get to the Colorado meeting, I'll throw in my
two cents' worth now.
A registry would have to be set up as a part of X3J13 or some other
"neutral" group in order to keep the registrar safe from big nasty
companies and their lawyers. I'm sure you've seen the kinds of hassles
that break out over trademarks and corporation names. We would have to
think carefully about what the rules should be for claiming a package
name. Otherwise some group will grab off all the good names and sell
them to the companies that have a real use for them.
In my view, companies and groups producing packages for widespread
distribution should be allowed to claim long package names that are not
likely to collide (e.g. XEROX-COMMON-LISP), but nobody should be allowed
to grab off short names like XCL. If you want to make XCL a local
nickname for Xerox Common Lisp, fine; I might want to use XCL as a
nickname for BERKELEY-X-IN-COMMON-LISP or for soemthing as yet undreamed
of.
-- Scott
∂25-Oct-87 1650 FAHLMAN@C.CS.CMU.EDU SETF-FUNCTION-VS-MACRO (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 16:50:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 19:50:33-EST
Date: Sun, 25 Oct 1987 19:50 EST
Message-ID: <FAHLMAN.12345418731.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: Msg of 23 Oct 1987 18:14-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
What we're saying is that using setf functions instead of setf macros
wherever you can is good programming style. I think the analogy to regular
macros is compelling. In the old days people used to over-use macros,
or even worse fsubrs, where they could just as well have used functions;
eventually it was widely realized that this was a bad idea, and that
macros should only be used where you are actually trying to do syntax
extensions. This didn't mean macros were obsolete, it just meant that
people better understood when it was good programming style to use them.
Another reason for using macros is because you don't trust the inline
declaration to do its job in some implementations under some conditions.
Which reminds me, we might want to say explicitly that
(proclaim '(inline (setf foo))) is allowed.
-- Scott
∂25-Oct-87 1728 FAHLMAN@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 17:27:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 25 Oct 87 20:28:25-EST
Date: Sun, 25 Oct 1987 20:28 EST
Message-ID: <FAHLMAN.12345425612.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Fahlman said he is inclined to support 1-SIGNAL-ERROR over
1-RETURN-OUTER.
All endorse 2-EXIT.
I can't reconstruct my earlier opinion on this, but I now favor
1-RETURN-INNER. I think that we should pin this down, rather than
letting it be an "is an error" case that will differ from one
implementation to another.
I also favor 2-EXIT.
-- Scott
∂26-Oct-87 0935 Moon@ALLEGHENY.SCRC.Symbolics.COM SETF-FUNCTION-VS-MACRO (Version 1)
Received: from [128.81.41.45] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 09:35:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 69583; Mon 26-Oct-87 12:26:44 EST
Date: Mon, 26 Oct 87 12:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12345418731.BABYL@C.CS.CMU.EDU>
Message-ID: <19871026172642.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 25 Oct 1987 19:50 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
....we might want to say explicitly that
(proclaim '(inline (setf foo))) is allowed.
Version 1 of the proposal said that. I didn't keep a copy of
version 2, so I can't check, but I assume version 2 said so also.
∂26-Oct-87 0939 EWeaver.pa@Xerox.COM [Moon: Issue: Pathname-subdirectory-list]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 09:39:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 87 09:39:22 PST
Date: Mon, 26 Oct 87 09:35 PST
From: EWeaver.pa@Xerox.COM
Subject: [Moon: Issue: Pathname-subdirectory-list]
To: Masinter.pa@Xerox.COM, Ghenis.pasa@Xerox.COM
cc: LispCore↑.PA@Xerox.COM, moon@stony-brook.scrc.symbolics.com,
cl-cleanup@sail.stanford.edu, ibuki!dbp@labrea.stanford.edu
Fcc: BD:>EWeaver>mail.babyl
In-Reply-To: The message of 23 Oct 87 15:37 PDT from Masinter.pa
Message-ID: <871026093537.5.EWEAVER@DUKE.isl.parc.xerox.com>
Line-fold: no
Date: 23 Oct 87 15:37 PDT
From: Masinter.pa
----- Begin Forwarded Messages -----
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
The solution to this problem that Symbolics has used for years works
quite well. The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level. In
addition to strings, in our system we allow certain keywords in the
list, enumerated below....
I might add that Kyoto / Ibuki Common Lisp uses this system too, and it
makes it quite simple to write code which ports to implementations which
run on other file systems. One notable case was a test suite which was
written on Unix and moved to VMS with no trouble.
I highly recommend this technique.
-------
∂26-Oct-87 1050 gls@Think.COM Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 10:49:45 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 26 Oct 87 13:49:21 EST
Received: by kali.think.com; Mon, 26 Oct 87 13:49:43 EST
Date: Mon, 26 Oct 87 13:49:43 EST
From: gls@Think.COM
Message-Id: <8710261849.AA06599@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, Hornig@scrc.symbolics.com,
Masinter.pa@xerox.com
In-Reply-To: Masinter.pa@xerox.com's message of 24 Oct 87 17:30 PDT <871024-173113-2262@Xerox>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
I will reiterate my support for 1-RETURN-INNER (as well as 2-EXIT).
We have here a classic case of the irresistible force (QUIT, dammit!)
versus the immovable mountain (UNWIND-PROTECT). I find that the
suggestion that situation 1 produce an error, but one that IGNORE-ERRORS
won't ignore, to be at least one level of epicycle too many.
Which mechanism are to we regard as primitive: the error system or the
catch/throw system? Or are they disjoint? I prefer, for simplicity, a
model in which the error system can be explained. as much as possible, as a
complex thing built on top of catch, throw, and unwind-protect.
--Guy
∂26-Oct-87 1157 Masinter.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 11:56:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 11:51:01 PST
Date: 26 Oct 87 12:50 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
In-reply-to: Ram@C.CS.CMU.EDU's message of Sun, 25 Oct 87 16:32 EST
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871026-115101-1826@Xerox>
I discarded the "is an error" possibility, not out of hand, but rather
because no one argued for it (Moon said in one message that we could
"wimp out" and take that option, but it didn't seem like he was favoring
it.)
I've read your message several times; I think what you are saying is
that you prefer
RETURN-INNER, RETURN-OUTER, IS-AN-ERROR (not written up), and
SIGNAL-ERROR.
in that order. Is that a correct reading of your position?
I think that your example
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
is a good one and should be in the proposal: it is a situation where
RETURN-INNER and RETURN-OUTER would have the same behavior; in such a
situation, it seems clear that SIGNALS-AN-ERROR seems out of place.
Here is another case to consider:
(DEFUN UNSTOPPABLE () (UNWIND-PROTECT (LOOP) (UNSTOPPABLE)))
Doesn't this have the same "unstoppable" property, completely orthogonal
to this issue? I.e., that it cannot be aborted by an asynchronous
"interrupt" unless they happen to come in at exactly the right moment?
Maybe I should have written it as
(labels ((unstoppable () (unwind-protect (loop) (unstoppable))))
(unstoppable))
∂26-Oct-87 1413 Masinter.pa@Xerox.COM Issue: PATHNAME-SUBDIRECTORY-LIST
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:13:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:08:46 PST
Date: 26 Oct 87 14:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
In-reply-to: EWeaver.pa's message of Mon, 26 Oct 87 09:35 PST
To: cl-cleanup@sail.stanford.edu
cc: ibuki!dbp@labrea.stanford.edu
Message-ID: <871026-140846-2061@Xerox>
I had marked the issue PATHNAME-SUBDIRECTORY-LIST as withdrawn; I
thought Moon's point ("the only reason to change the language would be
if we want to force all implementations to use the same representation
of structured directories, which might be difficult if some
implementation uses a strange file system with a directory feature we
haven't thought of.") was compelling.
However, I think there is some advantage to encouraging some consistency
of practice for those systems which do have subdirectory structures...
I'd recommend we postpone this issue for now...
∂26-Oct-87 1413 Masinter.pa@Xerox.COM Re: registry of *features* names
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:13:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:09:03 PST
Date: 26 Oct 87 14:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: registry of *features* names
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
25 Oct 87 19:40 EST
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871026-140903-2062@Xerox>
Perhaps we could ask ISI to do this task.
Perhaps the list need not be exclusive. I.e., you would have to provide
the name of the feature/package and a one-paragraph description of what
the name stood for and a name and address. The registry organization
would not attempt to allocate exlusive use. You could pick somebody
else's feature name if you liked; it would just be an information-only
registrar.
I believe that people will naturally try to avoid feature names in use
by others and that any obvious attempt to "corner the market" will be
ignored.
This isn't really an issue for CL-CLEANUP, except as it affects
SHARPSIGN-PLUS-MINUS-PACKAGE, which is hardly at all.
∂26-Oct-87 1458 Daniels.pa@Xerox.COM Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:58:50 PST
Received: from Salvador.ms by ArpaGateway.ms ; 26 OCT 87 14:50:59 PST
Date: 26 Oct 87 15:50 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
In-reply-to: Masinter.pa's message of 24 Oct 87 17:30 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Message-ID: <871026-145059-2151@Xerox>
I would like to add my support to 1-RETURN-INNER.
-- Andy. --
∂26-Oct-87 1459 Masinter.pa@Xerox.COM Re: Issue: TRACE-FUNCTION-ONLY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:58:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 14:53:55 PST
Date: 26 Oct 87 14:53 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: TRACE-FUNCTION-ONLY
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
25 Oct 87 17:31 EST
To: Fahlman@C.CS.CMU.EDU
cc: kempf%hplabsz@HPLABS.HP.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871026-145355-2156@Xerox>
I agree that it will be easier to get the issues passed if we separate
them. The notion that the features of TRACE as described in CLtL might
be applicable to (SETF fn) and other callable locations seems easy to
separate from trying to standardize what the "additional
implementation-dependent argument formats" are.
The latter should probably include a fairly complete Current Practice
section, for example. I'll allocate the name
TRACE-ARGUMENT-FORMAT-OPTIONS.
Jim: can you write up a version that doesn't include the :BREAK stuff? A
cross reference to TRACE-ARGUMENT-FORMAT-OPTIONS should probably be
included.
∂26-Oct-87 1616 RAM@C.CS.CMU.EDU Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 16:15:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 26 Oct 87 19:16:29-EST
Date: Mon, 26 Oct 1987 19:16 EST
Message-ID: <RAM.12345674667.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
In-reply-to: Msg of 26 Oct 1987 14:50-EST from Masinter.pa at Xerox.COM
Date: Monday, 26 October 1987 14:50-EST
From: Masinter.pa at Xerox.COM
To: Ram at C.CS.CMU.EDU
Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
I've read your message several times; I think what you are saying is
that you prefer
RETURN-INNER, RETURN-OUTER, IS-AN-ERROR (not written up), and
SIGNAL-ERROR.
Actually, I favor IS-AN-ERROR over RETURN-OUTER, since it would allow
me to implement RETURN-INNER. If I was writing an error system, I
might be more concerned about making this rigorously defined.
Here is another case to consider:
(DEFUN UNSTOPPABLE () (UNWIND-PROTECT (LOOP) (UNSTOPPABLE)))
Doesn't this have the same "unstoppable" property, completely orthogonal
to this issue? I.e., that it cannot be aborted by an asynchronous
"interrupt" unless they happen to come in at exactly the right moment?
Yep. That's real interesting. I suppose one could argue that it
isn't so important to prevent people from screwing themselves this
way, since real men don't write recursive functions. I see this as
demonstrating a fundamental property of UNWIND-PROTECT: it allows
transfer of control to be usurped.
Rob
∂26-Oct-87 1637 Masinter.pa@Xerox.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 16:37:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 16:34:46 PST
Date: 26 Oct 87 16:27 PST
From: Masinter.pa@Xerox.COM
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM, Pedersen.pa@Xerox.COM
Line-fold: 80
Message-ID: <871026-163446-2308@Xerox>
There's been no mail on this topic since May. My reading of the mail at
that time was that most folks were lukewarm; I've tried to capture that
in the discussion section below. I've rewritten this proposal to
include the GENERALIZE option and the watered down version in the
discussion. I'm not sure that is right. Oh well --- progress. Usual
caveats apply.
Has anyone had any new thoughts on this topic since May?
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Common Lisp already provides a facility called "displaced arrays" which
can be used to overlay one array on top of a portion of another, even if
the two are of different ranks, so that the two share storage or use the
awkward convention of creating a displaced array to the operand.
However, creating a displaced array merely to perform FILL, REPLACE or
EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
2) Modify the definition of MAKE-SEQUENCE to accept array descriptions
as well as vector descriptions.
3) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow
arrays. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected
functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY,
NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE,
NREVERSE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
and (ELT A 7) should return the same element as (AREF A 0 1 0). :START
and :END keywords would be interpreted relative to the vector, as would
the results returned by POSITION and SEARCH.
Extend the definitions of sequence functions whose result should be the
same shape as but not necessarily EQ to some argument. These functions
should deal with array arguments by returning an array of the same
shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.
Expressly forbid arrays as arguments to sequence functions that modify
the number of elements in the array because the shape would be
undefined. These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE,
REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a
sequence function, and it already has a well-defined behavior for
arrays. To test whether the arrays A and B, of different shapes, have
the same elements, one would write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, REDUCE, etc., or else they can build displaced vectors by hand
and pass them to the sequence functions when necessary.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back up
these proposed changes is already in place.
Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and the
SETF expander for ELT would have the side effect of extending the
remaining functions if they are written in the obvious way.
For example:
(DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
(LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
(DOTIMES (I (LENGTH SEQUENCE) RESULT)
(SETF (ELT RESULT I)
(IF (EQL (ELT SEQUENCE I) OLD-ITEM)
NEW-ITEM
(ELT SEQUENCE I))))))
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly
avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives
(which would be needed to take arbitrary k-dimensional slices out of
n-dimensional arrays, or to apply an operator across a specific
dimension of a multidimensional array), it requires just one rule:
treat arrays as displaced vectors.
Current Practice:
This is unlikely to be implemented anywhere since it has only very
recently been proposed.
Discussion:
This issue was discussed by the cleanup committee at length; this is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which
didn't explicitly depend on the shape of the array; that is, to modify
COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE,
NSUBSTITUTE, and MAP, and expressly forbid arrays as arguments to other
sequence functions, including LENGTH, ELT, FIND, POSITION, REDUCE,
SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, as well as SUBSEQ,
COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some
hedging over REDUCE and FIND, which often have non-positional uses, were
considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's
been building displaced vectors to pass to sequence functions when
necessary and really dislikes it.
We considered but discarded as unworkable an alternative where POSITION
and FIND might deal with "positions" as lists of array subscripts.
Another alternative considered would be to only adopt the COERCE change,
and require users who want to operate on arrays explictly perform, e.g.,
(COUNT item (COERCE x 'SEQUENCE)). This alternative would have the
lowest adoption cost; perhaps some implementations could optimize such
coercions.
The general reason for opposing this change is that it adds more
mechanism than it is worth. The general reason for liking it is that it
adds generality at little cost.
∂26-Oct-87 1655 Masinter.pa@Xerox.COM SETF-FUNCTION-VS-MACRO (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 16:55:41 PST
Received: from Salvador.ms by ArpaGateway.ms ; 26 OCT 87 16:54:30 PST
Date: 26 Oct 87 16:51 PST
From: Masinter.pa@Xerox.COM
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871026-165430-2342@Xerox>
I made the edits as previously announced. I added to Benefits the
improved utility of SETF independent of CLOS. I made a grammatical
change somewhere (I'm having trouble finding it), where I added a
semicolon and changed the active element of a sentence. I made several
changes in case.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The functions,
macros, and special forms defined in CLtL and listed in the References
section above need to be enhanced to accept such lists in addition to
symbols as function names, so that setf functions can be defined and
manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of
an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂26-Oct-87 1701 Masinter.pa@Xerox.COM Issue: SHADOW-ALREADY-PRESENT (version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:00:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 16:57:48 PST
Date: 26 Oct 87 16:57 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 3)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871026-165748-2355@Xerox>
There was no response to Moon's version 2. I modified the description
and rationale to emphasize that this is really two separate proposals,
one a clarification, the other a change (allowing strings.) I added a
few comments to the test cases. [I removed Moon's parenthetical remark
in brackets.] I added an endorsement to the discussion.
I don't understand this:
Epigram:
"Who knows what evil lurks in the hearts of men?"
I tried to imagine a package as the heart of a man and evil as a symbol,
lurking there, but it escaped me....
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate suggestions from
JonL
Version 3 Masinter 26-Oct-87
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
SHADOW is said to take symbols as arguments, however only the print-name
is meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the
PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as
well as symbols. The specification "the print name of each symbol is
extracted" is to be modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when
calling the function USE-PACKAGE. The name conflict is between a symbol
directly present in the using package and an external symbol of the used
package. This name conflict may be resolved in favor of the symbol
directly present in the using package by making it a shadowing symbol.
For this to work, SHADOW must add the symbol to the
PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string
should also be accepted. This is particularly useful to avoid problems
when compiling code in one package environment and loading it into a
slightly different package environment, where the symbol that was
referred to at compile time may not be present at load time. This is
particularly important because the symbol referred to by the print name
may be changed by evaluation of the SHADOW form. A close reading of
CLtL shows that one can already use (shadow '#:bar) in place of (shadow
'bar), to achieve much the same effect as (shadow "BAR"). But the user
should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. Kyoto
Common Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when
the symbol is already present in the package. It seems likely that we
will find several implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Adoption Cost:
It should be two one-line changes in one function.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve
the name conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Conversion Cost:
Technically this would be an incompatible change to implementations that
do not already behave as proposed, however it is difficult to conceive
of a user program that would require any conversion to cope with the
change. Some users might want to remove kludges that were only necessary
to get around the former misbehavior of SHADOW.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying
the language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
The cleanup committee endorses this proposal.
∂26-Oct-87 1721 Masinter.pa@Xerox.COM *FEATURES*, system package name
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:21:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 17:22:23 PST
Date: 26 Oct 87 17:22 PST
From: Masinter.pa@Xerox.COM
Subject: *FEATURES*, system package name
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871026-172223-2395@Xerox>
OK, I'll send out a message asking people to send in a list of feature
names and package names, and write a little hack to generate a sorted
list.
This is the format (this is just an example, of course):
(system "Xerox Common Lisp" From "Masinter.PA@Xerox.COM"
(Feature :COMMON Description "Common Lisp available")
(Feature :XEROX Description "Running in Xerox Common Lisp.")
(Feature :INTERLISP Description "The Interlisp programming language and
environment are available")
(Package "INTERLISP" nicknames ("IL") Description "Interlisp programming
language and environment")
(Package "XEROX-COMMON-LISP" nicknames ("XCL") Description "Xerox
extensions to Common Lisp")
(Package "XCL-USER" Description "Default package for Common Lisp windows
in Xerox Common Lisp environment")
(Package "LISP" nicknames ("COMMON-LISP" "CL") Description "As in CLtL,
package containing all Common Lisp symbols")
(Package "SYSTEM" nicknames ("SYS" "SI") Description "as in CLtL,
system internals")
(Package "D-ASSEM" Description "Xerox D-machine assembler")
(Package "FASL" Description "Xerox fast-loader")
(Package "COMPILER" nicknames ("XCLC") Description "Xerox Common Lisp
Compiler")
)
∂26-Oct-87 1738 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:38:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 26 Oct 87 20:34:03-EST
Date: Mon, 26 Oct 1987 20:33 EST
Message-ID: <FAHLMAN.12345688787.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Pedersen.pa@XEROX.COM
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
In-reply-to: Msg of 26 Oct 1987 19:27-EST from Masinter.pa at Xerox.COM
I'm in favor of this (the GENERALIZE option, that is). While I don't
think this is super-important, I do think that it is useful. Some of
the earlier impression of luke-warmness may have been due to the earlier
inclusion of two different options; I remember thinking that we should
adopt one or the other, but that I was indifferent as to which option
won.
I'm not sure about item 2 in the proposal: extending MAKE-SEQUENCE to
take an array specifier. That seems confusing to me. On the other
hand, I have never had occasion to use MAKE-SEQUENCE, so I don't care
too much about how far we stretch it.
-- Scott
∂26-Oct-87 1738 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:38:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 26 Oct 87 20:38:29-EST
Date: Mon, 26 Oct 1987 20:38 EST
Message-ID: <FAHLMAN.12345689595.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: SHADOW-ALREADY-PRESENT (version 3)
In-reply-to: Msg of 26 Oct 1987 19:57-EST from Masinter.pa at Xerox.COM
I don't understand this:
Epigram:
"Who knows what evil lurks in the hearts of men?"
I tried to imagine a package as the heart of a man and evil as a symbol,
lurking there, but it escaped me....
Obviously you didn't spend enough time listening to radio back in the
1930's. The next line is "The Shadow knows!" Does that help?
-- Scott
∂26-Oct-87 1741 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:41:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 26 Oct 87 20:41:57-EST
Date: Mon, 26 Oct 1987 20:41 EST
Message-ID: <FAHLMAN.12345690226.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: SHADOW-ALREADY-PRESENT (version 3)
In-reply-to: Msg of 26 Oct 1987 19:57-EST from Masinter.pa at Xerox.COM
I favor WORKS.
-- Scott
∂26-Oct-87 1742 @Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM Re: Issue: TRACE-FUNCTION-ONLY
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 17:42:06 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 26 Oct 87 17:38:44-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Mon, 26 Oct 87 13:18:48 PST
Received: from hplabsz.hpl.hp.com by hplms2; Mon, 26 Oct 87 13:18:14 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Mon, 26 Oct 87 14:17:43 pst
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: kempf%hplabsz@HPLABS.HP.COM, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TRACE-FUNCTION-ONLY
X-Mailer: mh6.5
In-Reply-To: Your message of Sun, 25 Oct 87 17:31:00 -0500.
<FAHLMAN.12345393345.BABYL@C.CS.CMU.EDU>
Date: Mon, 26 Oct 87 13:17:39 PST
Message-Id: <2540.562281459@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
SF> This doesn't really respond to the objection I raised. I didn't suggest
SF> that :BREAK was not worthwhile. I said that there are two distinct
SF> issues here: whether to extend TRACE to work for methods and setf
SF> functions, and whether to extend trace to do all sorts of other neat
SF> things. The former is probably not controversial, and I could
SF> support a proposal that contains just this.
I understand. I was trying to address both issues, but, as you've pointed
out, the :BREAK issue is somewhat more complex. I will rewrite the trace
proposal to remove the reference to :BREAK, redo the syntax to conform
to that currently in CLtL, and leave it up to someone else (who could
possibly be me at a later date) to deal with the break issue.
JK> While we're discussing this issue, another part of the proposal was to
JK> include a generic function, called TRACE-EXECUTION, which took as an
JK> argument an object representing an executable entity, like a method object,
JK> generic function, function, symbol, etc. An implementation specific method
JK> would run to arrange for tracing code to be inserted. Similar to
JK> PRINT-OBJECT, all implementations would have to implement tracing using
JK> this generic function. The advantage of this is that if someone extends
JK> CLOS/CL by including a new funcallable object, like, for example, a
JK> remote procedure call, debugging becomes extensible as well.
SF> This is going to be a fairly hairy proposal, I think, since you have to
SF> trace function names and not functions (unless you want to force
SF> implementors to do surgery on compiled function objects). I'd be
SF> interested in seeing the details of this proposal.
The intent of the proposal was to provide a system level interface for
extending debugging capability and for supporting current debugging
technology. Thus, since most current debuggers go through function names,
the method for implementing debugging on ordinary functions would
discriminate on symbols and would use the function wrapping technique
which most Lisps currently use for tracing. For tracing methods, the
debugging method would discriminate on a method object, and would wrap
the method function itself, since one way of implementing method
dispatch is to have the generic function use the method function directly
(in fact, this is how the PCL implementation works). More advanced Lisp
implementation technologies might make it possible to debug the invocation
of a function through the function definition object (fundef object), as
you've pointed out. By using a generic function, the usual advantages of
object oriented programming, in terms of system extensibility, would
be available, since the generic function would provide a portable interface
which each implementation could customize with the particular capibilities
that it can support.
Below is a copy of the proposal I submitted to the objects committee in
September. Note that it does not appear in the current draft of the Object
System specification, pending disposition of where, precisely, it belongs.
I'd appreciate hearing what you think of it.
jak
-------------------------------------------------------------------------------
Font note: UPPERCASE indicates bold, _this_ indicates italic.
TRACE-EXECUTION _object_ &KEY :ENVIRONMENT _[Generic Function]_
TRACE-EXECUTION discriminates on _object_ to select an implementation
specific method that arranges for the executable entity associated
with _object_ to be traced. The :ENVIRONMENT keyword parameter is for
those implementations which require environmental information to
arrange for tracing to occur. Implementations are required to provide
TRACE-EXECUTION as the system level entry point for implementing TRACE
functionality.
The exact nature and number of methods associated with TRACE-EXECUTION
will differ, depending on what executable entities can be specified
by TRACE, but every implementation needs to support methods which
dispatch on objects having the following classes:
SYMBOL-The function indicated by the symbol will be traced when invoked
in the environment.
METHOD-The method function is traced when invoked.
GENERIC-FUNCTION-The generic function is traced when the discriminator
code is invoked.
Implementations are encouraged to provide as many methods as the
implementation technology can support.
∂26-Oct-87 1831 Pedersen.pa@Xerox.COM Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 87 18:31:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 87 18:31:13 PST
Date: 26 Oct 87 19:30 PDT
From: Pedersen.pa@Xerox.COM
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
In-reply-to: Masinter.pa's message of 26 Oct 87 16:27 PST
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, Pedersen.pa@Xerox.COM
Message-ID: <871026-183113-2502@Xerox>
"Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and the
SETF expander for ELT would have the side effect of extending the
remaining functions if they are written in the obvious way.
For example:
(DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
(LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
(DOTIMES (I (LENGTH SEQUENCE) RESULT)
(SETF (ELT RESULT I)
(IF (EQL (ELT SEQUENCE I) OLD-ITEM)
NEW-ITEM
(ELT SEQUENCE I))))))"
I think this argument is a canard since any implementation worth its
salt will type dispatch for all sequence functions. The :generalize
proposal will inescapably induce a large number of small changes to
existing Common Lisp implementations.
It seems more esthetic to localize those changes in a single extension
(eg. (coerce x 'sequence)) rather than spreading them all over the
sequence functions.
J.P.
∂27-Oct-87 0933 CL-Cleanup-mailer TRACE Proposal (Version 2)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:33:28 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Tue 27 Oct 87 09:22:49-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Tue, 27 Oct 87 09:25:26 PST
Received: from hplabsz.hpl.hp.com by hplms2; Tue, 27 Oct 87 09:24:51 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Tue, 27 Oct 87 10:24:21 pst
To: Masinter.pa@xerox.com
Cc: fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu,
kempf%hplabs@hplabs.HP.COM
Subject: TRACE Proposal (Version 2)
X-Mailer: mh6.5
In-Reply-To: Your message of Wed, 21 Oct 87 09:58:09 -0700.
<24566.561833889@hplabsz>
Date: Tue, 27 Oct 87 09:24:16 PST
Message-Id: <15332.562353856@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
Larry:
As requested, this version makes no mention of a break option
and cross references the format note you mentioned. I've also added
a reference to Moon's SETF-CLOS proposal, since fixing TRACE will
also be needed for it.
Is there any sense of where/whether the TRACE-EXECUTION generic
function as a system entry point for extensible debugging is appropriate?
jak
(Font Note: UPPERCASE indicates bold, _this_ indicates italic)
-------------------------------------------------------------------------------
Issue: TRACE-CLOS
References: trace macro pp. 440-441
TRACE-ARGUMENT-FORMAT-OPTIONS
SETF-CLOS
Category: MODIFICATION
Edit history: Version 1, 21-Oct-87 Kempf
Version 2, 27-Oct-87 Kempf
Problem description:
With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of particular
methods to be traced, rather than invocation of the entire generic
function. In addition, the current specification of TRACE does not
allow tracing of functions associated with SETF "methods", of macro
functions, nor of lexically defined functions or functions invoked via. their
function definition objects. While this proposal does not attempt
to address the latter two problems, since identification and/or tracing of these
is likely to be implementation dependent, it does leave
open the option for those implementations which can arrange it.
Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)
TRACE _{function-spec}*_ _[Macro]_
UNTRACE _{function-spec}*_ _[Macro]_
Invoking TRACE with a function specification causes the function specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. UNTRACE undoes any tracing. Calling TRACE without
any arguments prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.
A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent; however,
every implementation is required to support the following:
_symbol_-Invocations of the function or macrofunction named by
_symbol_ via. _symbol_ as a global name are traced.
(METHOD _generic-function-name-specification_
_{method-qualifiers}_*
_parameter-specializer-name-list_
)
If the method whose parameter specializer list, generic function
name specification, and method qualifiers are listed is tracable,
then invocations through the generic function name specification
will be traced.
(SETF _symbol_)-If the SETF function having the name specification
is tracable, it will be traced (see proposal SETF-CLOS for
more information on SETF name specifications).
Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.
Rationale:
Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods. Adoption of the
SETF-CLOS proposal will require means of tracing SETF functions. It is
also not possible to easily trace either SETF functions or macrofunctions
today.
Current practice:
There is currently no way to trace SETF functions, aside from
macroexpanding a SETF form and using the resulting name in a
TRACE macro invocation. There is currently no way to trace macroexpansion
functions when they are invoked through their global names, except through
complicated use of *MACROEXPAND-HOOK*.
Adoption Cost:
The proposed syntax is upwardly compatible with the current Common Lisp
syntax. It will require the addition of function specification parsing
and wrapper code to trace SETF function executions and macrofunction
executions. When the Common Lisp Object System is fully implemented,
wrapper code for tracing method execution will also be required.
Cost of non-adoption:
Programmers will have to continue using a complicated set of Lisp
commands to arrange for SETF function and macrofunction tracing.
When the Common Lisp Object System is fully implemented, programmers
will have to use metaobject protocol functions to arrange for tracing.
Benefits:
Allow programmers to obtain information on individual method
invocations, and on SETF function and macrofunction invocations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
generating functions.
∂27-Oct-87 1307 CL-Cleanup-mailer TRACE Proposal (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 13:07:31 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 Oct 87 16:06:49-EST
Date: Tue, 27 Oct 1987 16:06 EST
Message-ID: <FAHLMAN.12345902265.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: kempf%hplabsz@HPLABS.HP.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: TRACE Proposal (Version 2)
In-reply-to: Msg of 27 Oct 1987 12:24-EST from kempf%hplabsz at hplabs.HP.COM
Several questions and comments:
1. Common Lisp does not currently require implementations to perform a
trace if the function in question has been "open coded", which category
may include compiled self-calls that do not go through the
symbol-function cell, etc. It should be made clear that this
modificaiton does not alter that provision.
2. It should be made clear that what is being traced in the case of a
macro is the call to the macro-expansion function, and not the execution
of the resulting code. Trace would print the calling form going in and
the expanded form being returned. I found the wording in the proposal a
bit confusing on this point. An example would help. Also make clear
that if macro-memoizing is going on, subsequent execution of the same
expansion code will not be traced.
Current practice:
There is currently no way to trace SETF functions, aside from
macroexpanding a SETF form and using the resulting name in a
TRACE macro invocation. There is currently no way to trace macroexpansion
functions when they are invoked through their global names, except through
complicated use of *MACROEXPAND-HOOK*.
Make that "no way that is standard across all implementations". Some
implementations do provide some of these services.
Adoption Cost:
The proposed syntax is upwardly compatible with the current Common Lisp
syntax. It will require the addition of function specification parsing
and wrapper code to trace SETF function executions and macrofunction
executions. When the Common Lisp Object System is fully implemented,
wrapper code for tracing method execution will also be required.
Can we assume that the Xerox people will put the necessary hooks into
the method-dispatching machinery? This would considerably reduce the
implementation cost for those of us who are using PCL as the basis for
our CLOS implementations.
Cost of non-adoption:
Programmers will have to continue using a complicated set of Lisp
commands to arrange for SETF function and macrofunction tracing.
When the Common Lisp Object System is fully implemented, programmers
will have to use metaobject protocol functions to arrange for tracing.
This is wrong, I think. The real cost is that implementations will
provide this functionality in varying forms and to varying degress, thus
making it harder for users to move between one Common Lisp system and
another. A few implementations may blow this off altogether, in which
case their users will be screwed as described above.
Benefits:
Allow programmers to obtain information on individual method
invocations, and on SETF function and macrofunction invocations.
... in a uniform way across all implemenations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
generating functions.
It is possible that some implementations have made extensions to TRACE
that are incompatible with this proposal. The only problem I can see
for those of us who currently allow a list of a function name and
options in place of simple symbols is that now it would be ambiguous if
someone wanted to trace invocations fo the SETF macro. We'll just
declare that illegal, since it would probably blow up on you anyway.
∂27-Oct-87 1334 CL-Cleanup-mailer Re: TRACE Proposal (Version 2)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 13:33:58 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Tue 27 Oct 87 13:23:09-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Tue, 27 Oct 87 13:25:29 PST
Received: from hplabsz.hpl.hp.com by hplms2; Tue, 27 Oct 87 13:25:11 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Tue, 27 Oct 87 14:24:45 pst
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: kempf%hplabsz@HPLABS.HP.COM, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: TRACE Proposal (Version 2)
X-Mailer: mh6.5
In-Reply-To: Your message of Tue, 27 Oct 87 16:06:00 -0500.
<FAHLMAN.12345902265.BABYL@C.CS.CMU.EDU>
Date: Tue, 27 Oct 87 13:24:42 PST
Message-Id: <18619.562368282@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
I'll fold your comments into Version 3.
> Can we assume that the Xerox people will put the necessary hooks into
> the method-dispatching machinery? This would considerably reduce the
> implementation cost for those of us who are using PCL as the basis for
> our CLOS implementations.
I don't claim to speak for Danny and Gregor, but I think the necessary
hooks are already there. I'm currently writing some code to do method
wrapping, since we have some enhancements in our local PCL which require
that invocation of a method function go through a function definition
object, and the tracing code supplied with PCL uses the portable
TRACE mechanism which requires function invocation to go through a symbol.
Standard metaobject protocol hooks are all I'm using. I'm sure there
would be no problem folding the code I'm doing into the release, if
the Xerox folks would rather implement it.
jak
∂27-Oct-87 1342 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 13:41:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 27 OCT 87 13:40:47 PST
Date: 27 Oct 87 13:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PROCLAIM-LEXICAL (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871027-134047-1530@Xerox>
I'm still not very happy with this, if only because the proposed
solution is not really motivated well by the problem described.
I attempted to reword the various discussion elements to reflect later
comments and agreements.
We let this one slip.
!
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37),
global variables (p68),
declaration specifiers (p157)
Category: ENHANCEMENT
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Problem Description:
CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
declared special, then a free reference to that name is a reference to
the special variable of that name, while a LAMBDA-binding of that name
indicates a binding of the lexical variable of that name. This would
mean that the following program is legal and that (TST) => 4:
(defun tst ()
(setq x 3)
(funcall (let ((x 4)) #'(lambda () x))))
However, if you feed this program to many Common Lisp compilers, a
warning message will be produced for the SETQ, saying something like
"Warning: X not declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so prominently
that a user would be hard put to say that a program which elicited such
warning messages was "correct" in that implementation. Unlike the
situation with unused variables, there is no possible declaration one
can write which suppresses the warning messages. This disagreement
between theory and practice should be mended somehow.
There is no way to "undo" a SPECIAL proclaimation. Several aspects of
variable declarations (including whether the variable is a constant,
never rebound, and the like) are impossible in portable Common Lisp,
although they exist in several implementations.
Proposal (PROCLAIM-LEXICAL:ADD-LEXICAL-GLOBAL-CONSTANT):
Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT,
which are mutually exclusive with the SPECIAL declaration specifier.
All four may be used as proclamations; only SPECIAL and LEXICAL may be
used as declarations.
A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
CONSTANT. A name is said to be unproclaimed if it has not been
proclaimed to be any of these four.
A free reference or assignment to a name is an error if it is
unproclaimed and undeclared. (While we expect many programming
environments to allow such references in interactive programming, no
portable program should rely on free references to unproclaimed and
undeclared variables; compiler warnings when encountering them are
encouraged.)
A LAMBDA-binding in the absence of a declaration or proclamation binds
the lexical variable.
SPECIAL proclamations and declarations behave as defined in CLtL.
LEXICAL proclamations have no effect other than to make the name cease
to be unproclaimed. LEXICAL declarations shadow all enclosing
declarations and proclamation of any of these four types. LEXICAL
declarations have the same scoping rules as SPECIAL declarations.
GLOBAL proclamations make it an error to bind the name.
CONSTANT proclamations make it an error to bind the name and an error to
assign to the name.
DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
All keyword symbols are automatically proclaimed CONSTANT.
A free reference or assignment accesses the same value regardless of the
declaration or proclamation. This is called the global value. SPECIAL
binding alters the global value within its extent. (Multiple process and
multiple processor systems will have to make their own definitions of
the extent of a SPECIAL binding, as noted on p.38 of CLtL--this proposal
does not address that.)
There is only one global value for a name and it is used by all free
references, all free assignments, and all SPECIAL bindings.
It is an error to re-proclaim a variable to a different class. (We
expect this issue to revisited by the compiler committee, see discussion
below.)
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Note that the second element of the list is 2. That is because the
special binding of y changes the global value to 4, and the
declared-lexical reference to y accesses the global value, since there
is no surrounding lexical binding.
Current Practice:
No implementations have all of these proclaimations, although some have
LEXICAL and some have GLOBAL.
Cost of adopting change:
This proposal requires no fundamental changes to implementations; the
superficial changes are to expose all of the primitive concepts which
are already available to programmers. Compilers and interpreters will
need to support LEXICAL as a declaration. Checking that variables
proclaimed as GLOBAL are not rebound is possible but not required.
Referencing or assigning to an unproclaimed and undeclared name "is an
error", not "signals an error", which allows but does not require an
implementation to issue a warning. This is a change from current
language but does not mandate a change from current practice.
Benefits:
LEXICAL proclamation enhances compatibility with Scheme. GLOBAL
proclamation allows more efficient deep-bound implementations.
Cost of converting existing code:
This change is upward compatible and will affect no existing code except
for code-walkers and other programs that analyze code.
Aesthetics:
The distinction between special and lexical variables is one of the more
confusing aspects of Common Lisp to those used to programming in Scheme.
Some might prefer to have a separate syntax (instead of LET with special
declarations) to do dynamic bindings. However, for the most part, such
changes are orthogonal to the issues raised here.
Making primitive concepts explicitly available can only enhance
aesthetics.
Discussion:
The original Common Lisp designers had difficulty with this issue;
putting in these features was part of the original intent, but time
didn't allow.
The following discussion carefully uses different words for kinds of
"cells" and kinds of "bindings". Lack of differentiation here has led to
a lot of confusion. Terminology in this area differs in writings about
Lisp and other programming language.
"Cells" are conceptual locations that remember a value and can be read
and written. Sometimes these conceptual locations are implemented by
actual memory locations, and sometimes they aren't, but that's an
implementation detail and is irrelevant here. (Sometimes these are
called variables, but other times the word "variable" means something
else, so for the sake of clarity I'm not going to use the word
"variable".)
Common Lisp has several kinds of cells. Local cells have lexical scope,
while global cells have global scope and can be referenced from anywhere
except where they are shadowed by a local cell referenced by the same
name.
Common Lisp has two kinds of binding: Lexical binding creates a new
cell. Special binding saves the value of a cell, gives it a new value
during the extent of the binding, and later restores the old value. We
know that special binding saves and restores because of what other
functions see when they read the cell. (This should not be confused by
issues of shallow-bound versus deep-bound implementation, which are
irrelevant here: cells are not the same thing as memory locations.)
In principle, all cells have indefinite extent: they exist as long as a
reference to them is possible. However, for most local cells, in the
absense of a closure, no reference to the cell is possible once the
invocation which created the cell exits; in those cases, the cell has
dynamic extent.
Common Lisp has a fairly complicated set of rules for how to determine
what cell is referenced when a program mentions a variable name.
("lexically free" means outside of all bindings of that name, regardless
of whether those bindings are special or lexical.)
1. If the reference is lexically free, use the global cell.
2. Otherwise, in the absence of a SPECIAL declaration use the cell
that
was affected by the innermost binding; if that binding was special,
use the global cell; if it was lexical, use the local cell created
by that binding.
3. Otherwise, the SPECIAL declaration forces use of the global cell.
We certainly do not want to introduce a third kind of cell, because that
would lead to a great deal of confusion. Nor do we want to introduce a
third kind of binding. What we -are- trying to accomplish is to make
the primitive concepts orthogonally available. An example of a problem
we have right now that needs to be fixed is that there is no way to say
that a name is not misspelled without simultaneously saying that
bindings of that name should be special rather than lexical. These
concepts should be available as separate constructs.
There are four things that we would like to be able to proclaim about a
variable name (aside from TYPE):
- the default kind of binding if no declaration specifies which kind
- the name is not misspelled so don't warn about free references
- it is illegal to specially bind the global cell, because it is
a constant or because we want to optimize the performance of a
deep-binding implementation
- it is illegal to store into the global cell, because it is a constant
It is already possible in Common Lisp to proclaim all four of these
things, but some of them are mixed up with other concepts and not
separately available. Let's pick names for the four kinds of
proclamations, and let's also agree that any proclamation serves the
"not misspelled" purpose. Let's further agree that these four
proclamations are mutually exclusive.
LEXICAL -- does nothing other than "not misspelled"
SPECIAL -- changes the default kind of binding from lexical to
special
GLOBAL -- makes it illegal to specially bind the global cell
CONSTANT -- makes it illegal to store into the global cell
CONSTANT implies GLOBAL because special-binding is storing
SPECIAL exists now. LEXICAL is its logical complement. CONSTANT exists
now but only buried inside the DEFCONSTANT macro. GLOBAL exists now but
only when implied by DEFCONSTANT. This proposal makes them all
explicitly available.
It is appropriate to make CONSTANT and GLOBAL proclamations change the
default kind of binding to "illegal", rather than leaving it lexical, to
avoid unforseen interactions.
Fahlman added the following on question of overriding an old
proclaimation by issuing a new one:
We want to allow a variable to be re-proclaimed for two reasons: to
correct proclmations issued in error by the user, without having to kill
off the Lisp and start over, and to make it easier to merge programs
written by two different programmers. (The latter reason may be bogus
-- they shouldn't be in the same package anyway -- but there are times
when a quick fix is extremely handy.) On that other hand, we want the
compiler to be able to wire certain things in tight as a result of these
proclamations, so we need to make clear that if you proclaim something
to be GLOBAL, compile some code, then proclaim it to be SPECIAL and then
compile some more code the rebinds this variable, you may not get what
you expect. Same with unconstantifying a constant.
The current considerations of the compiler committee might give a
framework for explaining what the rules are within that framework.
However, given the current state of things, it is best to say that it
"is an error" to re-proclaim a variable into a different class -- this
says that portable code cannot do this and count on the result -- but
that implementations are strongly urged to allow this re-proclamation as
a way of correcting erroneous proclamations, perhaps issuing a warning
or signalling a correctable error whenever a proclamation actually gets
changed.
The cleanup committee considered numerous alternatives to this proposal,
including one where global lexical binding was separate from global
dynamic binding, various rules for not allowing a global variable to be
shadowed by a special declaration and the like.
∂27-Oct-87 1450 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 14:50:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 27 OCT 87 14:51:08 PST
Date: 27 Oct 87 14:50 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM
Line-fold: 80
cc: Masinter.pa@Xerox.COM
Message-ID: <871027-145108-1674@Xerox>
I've rewritten this to include only the 2-EXIT, 1-RETURN-INNER
combination, naming it CONTINUATION-MODEL.
Is this ready for release?
!
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
References: UNWIND-PROTECT (p140, p142, p39)
Issue IGNORE-ERRORS, Draft error proposal.
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 27-Feb-87
Version 2 by Masinter 24-Oct-87
Version 3 by Masinter 27-Oct-87
Problem Description:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
Situation 0. Transfer to another point within the cleanup form.
(UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX))
There is no ambiguity about how this form is to be interpreted.
Effectively:
. 3 evaluates to itself, which is queued for return
from the UNWIND-PROTECT.
. The BLOCK expression is entered, 4 is returned to
it and discarded because this is a not-for-value
situation.
. XXX is printed, XXX is returned by the PRINT and
that value is discarded because this is a not-for-value
situation.
. The 3 which was yielded earlier is retrieved and
returned as the value of the UNWIND-PROTECT.
Situation 1. Transfer to a point inside the point to which control
would have transferred.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found within the scope of the target of the
pending THROW (to FOO).
Situation 2. Transfer to a point outside the point to which return would
already have been. For example:
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
This is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW (to FOO).
What is the appropriate behavior for situation 1 and situation 2 and
similar ones? For example, suppose that when WITH-OPEN-FILE tries to
close the file upon unwinding, it signals an error, and the condition
handler also attempts to throw? The question applies to all non-local
transfers, whether performed by THROW, RETURN-FROM, RETURN, GO.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL):
In all cases, a transfer of control within an UNWIND-PROTECT cleanup
form to a point outside of the UNWIND-PROTECT causes the original
control transfer which initialed the execution of the cleanup forms to
be abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a
non-local exit to a point outside of the scope of the UNWIND-PROTECT,
but still within the dynamic scope of of the target of the original
non-local exit succeeds, and the original pending exit is discarded. For
example, in Situation 1, the pending seek for tag FOO is discarded by
the second THROW to BAR and the value 4 is transfered to (CATCH 'BAR
...), which returns 4. The (CATCH 'FOO ...) then returns the 4 because
its first argument has returned normally. XXX is not printed.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.) For
example, in Situation 2, the value 4 is returned from the (CATCH 'BAR
...); XXX is not printed.
In no case will UNWIND-PROTECT cleanup forms ever be attempted more than
once.
Rationale:
Current Practice:
Some implementations generate garbage code in situations 1 and 2. Some
have differing behavior compiled and interpreted.
Most that have implementations seem to implement the proposed semantics
for situation 2, but there is some divergence in Situation 1. For
example, Spice Lisp and Xerox implement the proposed semantics, while
Symbolics Common Lisp signals an error.
Adoption Cost:
While require some compiler modifications in some implementations, in
most cases, that work was in order anyway since compilers may currently
be doing nothing particularly useful or defensible with the code in
question.
Benefits:
Having this situation uniformly treated seems critical:
Programs that do this accidentally should behave the same on all systems
so that bugs can be detected and fixed very early rather than being
found later on a system which disagrees.
Programs that do this on purpose generally are trying to do something
fairly intricate and really need to be able to depend on it being
uniformly treated. A portable error/signal system and debugger may be
among these. For example, one programmer created his own "top level", to
which the system "abort" character would return, by doing:
(DEFUN MY-TOPLEVEL ()
(TAGBODY LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL)
(GO LOOP))))
Aesthetics:
This proposal is more intuitive to programmers who reason about programs
in terms of continuation passing. It falls out of the normal scoping
rules as a consequence of the fact that the cleaup code is evaluated in
the lexical and dynamic environment in which the UNWIND-PROTECT form
appears. The action of THROW is usefully described by saying that it is
just like any other function. It happens to discard the current
continuation, run some cleanup things (like variable unbindings and
UNWIND-PROTECT actions), and transfer control elsewhere in the program.
In doing so, the function uses data structure primitives not generally
available to other programs, but it is not linguistically different and
receives no special exemption with regard to THROWs or other non-local
transfers of control done within its execution. A THROW from within an
UNWIND-PROTECT cleanup is not different than one in any other code; it
discards the ongoing action (stack unwinding) and replaces it by another
action (as it happens, another stack unwinding). The previous unwind is
never resumed.
Conversion Cost:
Most user programs don't do this so the cost of converting existing code
is probably minimal. (There is some evidence that there are programs
that expect this behavior, so there is no conversion cost for those
programs.)
Discussion:
Two alternatives for situation 2 were seriously considered: that it
should signal an error, and that it the second non-local exit instead
continues the original (more extensive) one; e.g., in Situation 1, the
second THROW to BAR would be discarded in lieu of continuing the THROW
to FOO.
Either of these alternatives would help prevent users from (either
intentionally or unintentionally) creating situations where it is
impossible to abort a computation with a THROW or other non-local return
(e.g., an interrupt implemented via THROW.)
For example, given
(LOOP
(CATCH 'FOO
(UNWIND-PROTECT (LOOP)
(THROW 'FOO T))))
With this proposal there is no way of exiting such a form. Signalling an
error would prevent programmers from getting into this unfortunate
situation.
However, similar "unstoppable" loops can be created, without resorting
to non-nested non-local transfers within UNWIND-PROTECT clauses; for
example:
(LABELS ((HA () (UNWIND-PROTECT (LOOP) (HA)))) (HA))
While it would be for a programmer to accidentally create such an
unstoppable loop, the user has pretty clearly asked to have a loop that
cannot be exited and deserves to have that request carried out.
One implication is that it is likely that programming environments need
to provide some mechanism other than THROW to stop a truly run-away
computation.
An interesting example which supports this proposal is one where there
are two BLOCKs
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated
interchangably, signalling an error in this situation would be
inappropriate.
∂27-Oct-87 1901 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 19:01:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 27 OCT 87 19:02:05 PST
Date: 27 Oct 87 19:01 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
In-reply-to: Masinter.pa's message of 27 Oct 87 14:50 PST
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871027-190205-2029@Xerox>
In the first paragraph of the proposal proper, "...the original control
transfer which initialed the execution..." should read "...the original
control transfer which initiated the execution..."
Otherwise, I'm reasonably satisfied with it.
-- Andy. --
∂27-Oct-87 2015 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 20:15:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 Oct 87 23:15:16-EST
Date: Tue, 27 Oct 1987 23:15 EST
Message-ID: <FAHLMAN.12345980284.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Subject: Issue: PROCLAIM-LEXICAL (Version 4)
In-reply-to: Msg of 27 Oct 1987 16:40-EST from Masinter.pa at Xerox.COM
I'm still not very happy with this, if only because the proposed
solution is not really motivated well by the problem described.
I agree that the problem description needs work. We started discussing
this set of issues again because someone was grousing about spurious
warnings, but it quickly became apparent that this was just a symptom of
a badly snarled system for declaraing variable types. The proposal
tries to rationalize this mess. Probably the right move is to take some
of the stuff from the "benefits" section, negate it, and put the result
into the problem section.
I support the substance of thsi proposal now. I am still uneasy about
the statement that it "is an error" to change a variable's proclaimed
binding-type. I'd be happy to see implementations issue a warning in
this case, but I'd also like to see a guarantee that the new
proclamation will take effect, except perhaps in the case of GLOBAL or
CONSTANT proclamations that have already had an irreversible effect on
compiled code. Otherwise, if you accidentally issue the wrong
proclamation, you've got no choice but to nuke the Lisp.
I suppose this means that KMP and I will have to have another fight
about whether it is OK to issue a warning in a case that neither "is an
error" nor "signals an error". We're probably never going to agree on
what warnings are for, so let me state in advance that I think I'm
right, but I would settle for a formula that says re-proclaiming is an
error, but implementors are ENCOURAGED to handle it in a way that lets
the re-proclamation take effect.
By the way, last time around I argued pretty strongly that
implementations should be forced to accept SETQ of unproclaimed
variables, at least in the interpreter, so that the time honoered
practice of saying (SETQ FOO *) to the read-eval-print loop would not be
disrupted. I'm willing to yield on this now. I've decided that I can
define a macro that will turn (STUFF FOO *) into the proper
proclaim/setq pair. But I do want to be able to undo that proclamation
later without nuking hte Lisp.
-- Scott
∂28-Oct-87 0705 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 4)
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 07:05:03 PST
Date: Wed, 28 Oct 87 10:08:20 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL (Version 4)
To: Masinter.pa@XEROX.COM
cc: JAR@AI.AI.MIT.EDU, cl-cleanup@SAIL.STANFORD.EDU,
willc%tekchips.tek.com@RELAY.CS.NET,
chapman%aitg.dec@DECWRL.DEC.COM
In-reply-to: Msg of 27 Oct 87 13:40 PST from Masinter.pa at Xerox.COM
Message-ID: <276333.871028.JAR@AI.AI.MIT.EDU>
The idea, presented in PROCLAIM-LEXICAL versions 2-4, that special
variables have corresponding "cells", really bugs me. It means that
binding and unbinding are to be thought of as side-effects. The
environment model of binding seems much more elegant and modular to me;
note that the McCarthy's original Lisp interpreter, Steele's Art of the
Interpreter, and Scott/Strachey-style descriptions of programming
languages, even dynamically scoped languages, all describe binding in
terms of environments. If I were describing the semantics of Common
Lisp, I'd say that the inputs to the (semantic) interpreter were: an
expression, a lexical environment (for lexical variables, block names,
declarations, etc.), a dynamic environment (for special variables, catch
tags, and unwind-protections), a store (to find the values currently
stored in locations like the cars and cdrs of conses), and a
continuation. Now it's certainly possible to have a "cell" model of
evaluation which is completely equivalent to this; you just multiplex
the store and dynamic environment arguments, and make sure that
unbinding happens at the right time. These two semantic models
correspond to deep- and shallow-bound implementations, which as we all
know are equivalent as far as their behavior is concerned.
I would be much happier if the description of special variables was in
terms of dynamic environments rather than in terms of "cells" and
side-effects. This is what I was beginning to try to do with version 1
of the proposal. (The actual behavior of Common Lisp is less important
to me than its mode of description, so long as I can do what I want to
do, which versions 1-4 all do.) It's easier to derive the shallow
semantics from the deep semantics than vice versa, and it's
correspondingly easier for users and implementors to understand. The
environment model also adheres more closely to standard practice in the
rest of the programming languages community -- although I guess the Lisp
community has never been afraid of provincialism before...
∂28-Oct-87 0926 CL-Cleanup-mailer TRACE Proposal (Version 3)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 09:24:37 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 28 Oct 87 09:21:13-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Wed, 28 Oct 87 09:22:10 PST
Received: from hplabsz.hpl.hp.com by hplms2; Wed, 28 Oct 87 09:21:33 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Wed, 28 Oct 87 10:21:01 pst
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, fahlman@c.cs.cmu.edu
Subject: TRACE Proposal (Version 3)
X-Mailer: mh6.5
Date: Wed, 28 Oct 87 09:20:59 PST
Message-Id: <988.562440059@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
(Font Note: UPPERCASE indicates bold, _this_ indicates italic)
--------------------------------------------------------------------------------
Issue: TRACE-CLOS
References: trace macro pp. 440-441
TRACE-ARGUMENT-FORMAT-OPTIONS
SETF-CLOS
Category: MODIFICATION
Edit history: Version 1, 21-Oct-87 Kempf
Version 2, 27-Oct-87 Kempf
Version 3, 28-Oct-87 Kempf
Problem description:
With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of particular
methods to be traced, rather than invocation of the entire generic
function. In addition, the current specification of TRACE does not
allow tracing of functions associated with SETF "methods", of macro
functions, nor of lexically defined functions or functions invoked via. their
function definition objects. While this proposal does not attempt
to address the latter two problems, since identification and/or tracing of these
is likely to be implementation dependent, it does leave
open the option for those implementations which can arrange it.
Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)
TRACE _{function-spec}*_ _[Macro]_
UNTRACE _{function-spec}*_ _[Macro]_
Invoking TRACE with a function specification causes the function specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. UNTRACE undoes any tracing. Calling TRACE without
any arguments prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.
A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent; however,
every implementation is required to support the following:
_symbol_-Invocations of the function or macrofunction named by
_symbol_ via. _symbol_ as a global name are traced.
(METHOD _generic-function-name-specification_
_{method-qualifiers}_*
_parameter-specializer-name-list_
)
If the method whose parameter specializer list, generic function
name specification, and method qualifiers are listed is tracable,
then invocations through the generic function name specification
will be traced.
(SETF _symbol_)-If the SETF function having the name specification
is tracable, it will be traced (see proposal SETF-CLOS for
more information on SETF name specifications).
Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.
Note that this proposal does not change the current Common Lisp
specification in the area of "open-coded" functions. In particular,
implementations need not arrange for tracing of "open-coded" functions,
including compiled self calls which do not go through the symbol-function
cell.
In the case of tracing macro expansions, the trace is of the call to
the macroexpansion funtion and not of executing the return code. Thus the
trace function need only print the calling form arguments and the
expanded form being returned. As with "open-coded" functions, implementations
which memoize the expansion code are under no obligation to report trace
information once the macro code has been memoized. The example section
provides an example of an interactive session tracing a macro expansion.
Example:
1 [LISP] > (defmacro test-trace (arg)
1 [LISP] > `(format T "~S~%" ,arg)
1 [LISP] > )
TEST-TRACE
2 [LISP] > (trace test-trace)
((MACROFUNCTION TEST-TRACE))
3 [LISP] > (test-trace 'foo)
Entering macrofunction TEST-TRACE with arguments:
(QUOTE FOO)
Leaving macrofunction TEST-TRACE with return values:
(FORMAT T "~S~%" (QUOTE FOO))
FOO
4 [LISP] >
Rationale:
Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods. Adoption of the
SETF-CLOS proposal will require means of tracing SETF functions. It is
also not possible to easily trace either SETF functions or macrofunctions
today.
Current practice:
There is currently no way which is standard across all implementations
to trace SETF functions, aside from macroexpanding a SETF form and using
the resulting name in a TRACE macro invocation. There is currently no way
which is standardized across all implementations to trace macroexpansion
functions when they are invoked through their global names, except through
complicated use of *MACROEXPAND-HOOK*.
Adoption Cost:
The proposed syntax is upwardly compatible with the current Common Lisp
syntax. It will require the addition of function specification parsing
and wrapper code to trace SETF function executions and macrofunction
executions. When the Common Lisp Object System is fully implemented,
wrapper code for tracing method execution will also be required.
Cost of non-adoption:
Implementations will provide this functionality in varying forms and
to varying degrees, thus making it harder for users to move between
one Common Lisp system and another. Some implementations may choose
not to provide the functionality, in which case users will suffer.
Benefits:
Allow programmers to obtain information on individual method
invocations, and on SETF function and macrofunction invocations
in a uniform way across all implementations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
generating functions. Some implementations which have made extensions
to TRACE will need to accommodate those extensions with the additional
syntax.
∂28-Oct-87 1307 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Oct 87 13:04:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 87 13:05:07 PST
Date: 28 Oct 87 13:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: TRACE-FUNCTION-ONLY
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
27 Oct 87 16:06 EST
To: kempf%hplabsz@HPLABS.HP.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871028-130507-3318@Xerox>
I'd like to see added to the discussion section that there are
additional features of TRACE not being discussed at this time but being
included in other proposals. I think we also need to say that we
understand that TRACE is part of the environment rather than the
language and as such there are different criteria for evaluating
compliance. (E.g., we might want to define a level of acceptability for
embedded systems which includes all of the language but none of the
environment, e.g., system intended to be imbedded in an office
machines.)
I'd called this issue TRACE-FUNCTION-ONLY; the SETF proposal was called
SETF-FUNCTION-VS-MACRO in the tradition of naming issues after the
problems they solve rather than after one of the proposed solutions. I'd
like to see a few minor modifications to put this in the standard format
of cleanup proposals.
Finally, maybe I'm feeling grumpy today, but I've little enthusiasm for
this. Frankly, all of the programming environment features one might
standardize, TRACE is one of the most useless; I don't think I've TRACEd
anything for the last 6 months. Adding breakpoints, yes, TRACE, no; the
information printed is either too much or not enough.
∂28-Oct-87 1321 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 87 13:21:43 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 266202; Wed 28-Oct-87 16:23:03 EST
Date: Wed, 28 Oct 87 16:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <871027-145108-1674@Xerox>
Message-ID: <871028162111.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Version 3 of the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT writeup is incomplete.
It lacks a rationale. Version 1 had a rationale which you might be able to
resurrect.
Version 3 also seems to have lost the endorsement summary. I hope it will be
replaced before presentation to the committee.
Modulo these minor issues, I support the CONTINUATION-MODEL proposal as stated.
It takes the position I had endorsed when I originally introduced this issue.
∂28-Oct-87 1413 CL-Cleanup-mailer My silence
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 87 14:13:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 266285; Wed 28-Oct-87 17:15:04 EST
Date: Wed, 28 Oct 87 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: My silence
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19871028221347.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
My lack of response to the enormous volume of mail that has been
sent to CL-Cleanup recently does not indicate lack of interest.
Right now my priorities are 1. meeting a very close product
deadline, 2. CLOS, 3. CL-Cleanup, and 4. other commitments I
have made and am already way behind on. I guess eating, sleeping,
and socializing are in there someplace as well. I promise to
respond thoughtfully to some of these issues early next week.
∂28-Oct-87 2111 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 87 21:11:12 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 266727; Thu 29-Oct-87 00:12:52 EST
Date: Thu, 29 Oct 87 00:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: Masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <871026-165430-2342@Xerox>
Message-ID: <871029001055.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
In general, I support the idea of the SETF-FUNCTIONS proposal for this issue.
I'd like to see some presentation issues get cleared up, though, before it
goes to X3J13...
* Currently the proposal section says:
"The functions, macros, and special forms defined in CLtL and listed
in the References section above need to be enhanced to accept such
lists in addition to symbols as function names, so that setf functions
can be defined and manipulated."
I'm sympathetic to this in principle but I don't think this is adequately
explicit for us to vote in. For example,
. I think we have to explicitly mention notation issues such as the
syntax for INLINE and FTYPE declarations in the proposal section.
. I think we have to mention how DEFUN and FLET are extended, not just
provide examples that seem to imply something.
. We need to talk about what FMAKUNBOUND, FBOUNDP, DISASSEMBLE,
DOCUMENTATION, etc. individually/explicitly. It's ok for Moon to have
proposed the issue to CL-Cleanup at this level of sketchiness so he
didn't have to work too hard to get it on the table, but I think we
should flesh this out before it goes to the full committee. Experience
with places in CLtL that ask the reader to extrapolate should have
taught us by now that this is pretty dangerous to depend upon.
* Moon's reply to Gregor's remark about package::|SETF -name-| is important.
In general, such an approach would require the space of symbols in the
given package to be extended if you wanted to make something SETF-able
which had not previously been. Using the list notation does not have this
bad misfeature. This should definitely be mentioned in the discussion.
* The lettered items in the discussion (paths not taken) should be worded
in some sort of parallel style. As it is now, some seem to be questions and
some statements.
∂29-Oct-87 0814 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 08:14:17 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 08:10:36-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Thu, 29 Oct 87 08:13:36 PST
Received: from hplabsz.hpl.hp.com by hplms2; Thu, 29 Oct 87 08:13:13 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Thu, 29 Oct 87 09:12:46 pst
To: Masinter.pa@Xerox.COM
Cc: kempf%hplabsz@HPLABS.HP.COM, cl-cleanup@Sail.stanford.edu
Subject: Re: Issue: TRACE-FUNCTION-ONLY
X-Mailer: mh6.5
In-Reply-To: Your message of 28 Oct 87 13:04:00 -0800.
<871028-130507-3318@Xerox>
Date: Thu, 29 Oct 87 08:12:43 PST
Message-Id: <17103.562522363@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
> I'd like to see added to the discussion section that there are
> additional features of TRACE not being discussed at this time but being
> included in other proposals. I think we also need to say that we
> understand that TRACE is part of the environment rather than the
> language and as such there are different criteria for evaluating
> compliance. (E.g., we might want to define a level of acceptability for
> embedded systems which includes all of> the language but none of the
> environment, e.g., system intended to be imbedded in an office
> machines.)
I can't seem to find the draft of Version 3 which I sent off yesterday,
probably because I posted it to cl-cleanup only and didn't include myself.
Since I'm not on the cl-cleanup list, I didn't get a copy. Larry, could
you either send me a copy back, or fold these commments into Version 4
yourself? Thanks in advance.
> Finally, maybe I'm feeling grumpy today, but I've little enthusiasm for
> this. Frankly, all of the programming environment features one might
> standardize, TRACE is one of the most useless; I don't think I've TRACEd
> anything for the last 6 months. Adding breakpoints, yes, TRACE, no; the
> information printed is either too much or not enough.
I pretty much agree with these sentiments, however, I think that, since
most implementors have already extended TRACE to include breakpoints,
they will probably fold those extensions into the extended TRACE. This
will, of course, mean that the break extensions will remain nonstandard,
but until everyone can agree on what extensions are correct, I think that's
the best we can hope for.
I'm more concerned about a lack of an extensible interface at the system
level. This is what TRACE-EXECUTION is supposed to be, along with a
generic function like PRINT-TRACE. The read-eval-print loop debugging
which the TRACE macro was designed for is becoming obsolete rapidly,
as people move to more sophisticated environments. It would be nice to
have a set of portable interface "plugs", into which people could plug
their experimental debugging interfaces. Without plug-compatible system
level interfaces, porting debugging extensions will require extensive
source access, which some implementors have been reluctant to give.
jak
∂29-Oct-87 1048 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Oct 87 10:47:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 267277; Thu 29-Oct-87 13:43:12 EST
Date: Thu, 29 Oct 87 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871029001055.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871029184314.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 29 Oct 87 00:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
In general, I support the idea of the SETF-FUNCTIONS proposal for this issue.
I'd like to see some presentation issues get cleared up, though, before it
goes to X3J13...
* Currently the proposal section says:
"The functions, macros, and special forms defined in CLtL and listed
in the References section above need to be enhanced to accept such
lists in addition to symbols as function names, so that setf functions
can be defined and manipulated."
I'm sympathetic to this in principle but I don't think this is adequately
explicit for us to vote in. For example,
. I think we have to explicitly mention notation issues such as the
syntax for INLINE and FTYPE declarations in the proposal section.
. I think we have to mention how DEFUN and FLET are extended, not just
provide examples that seem to imply something.
. We need to talk about what FMAKUNBOUND, FBOUNDP, DISASSEMBLE,
DOCUMENTATION, etc. individually/explicitly. It's ok for Moon to have
proposed the issue to CL-Cleanup at this level of sketchiness so he
didn't have to work too hard to get it on the table, but I think we
should flesh this out before it goes to the full committee. Experience
with places in CLtL that ask the reader to extrapolate should have
taught us by now that this is pretty dangerous to depend upon.
I don't understand what you find insufficiently explicit about this now.
Do you mean that we should say
(defun (setf foo) ...) works like (defun foo ...)
(flet (((setf foo) ... works like (flet ((foo ...
(declare (inline (setf foo))) works like (declare (inline foo))
(symbol-function '(setf foo)) works like (symbol-function 'foo)
and so on for all the rest of them?
That seems pretty pointless to me. You must mean something more profound,
but I don't see what.
....
∂29-Oct-87 1200 CL-Cleanup-mailer Issue names
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 29 Oct 87 11:59:58 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134939; Thu 29-Oct-87 14:17:34 EST
Date: Thu, 29 Oct 87 14:16 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue names
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871029141642.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
If possible, could people please not rename issues mid-stream? Since
probably only half of the people on this list seem to reliably use an
In-Reply-To field in their message, the issue name is the only thing
tying a conversation together into a single thread for filing purposes.
In my view, the issue names should just be unique identifiers which are
perhaps originally mnemonic, but whose most important aspect is that
they let me reliably select a set of messages and know that if I've read
all those messages, I am up to date in that conversation thread. When
the proposed function AREF-1D was renamed, for example, the issue name
was retained for the sake of those trying to track the conversation.
The name change from TRACE-CLOS to TRACE-FUNCTION-ONLY left me with two
files containing half a conversation each. It took a while for me to
figure out what happened.
If someone absolutely thinks that some issue name is so awful that it is
keeping them from getting work done on the issue and that only a name
change will solve the problem, I'd personally appreciate it if they
could make the renaming -very- prominent, mentioning both the old name
and the new name. eg, by a subject line like:
Subject: TRACE-FUNCTION-ONLY (formerly TRACE-CLOS)
It would be helpful if Masinter's occassional issue summaries would
mention the obsolete names, too, just for reference.
Thanks.
∂29-Oct-87 1241 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
Received: from [128.81.41.234] by SAIL.STANFORD.EDU with TCP; 29 Oct 87 12:41:27 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105872; Thu 29-Oct-87 15:17:24 EST
Date: Thu, 29 Oct 87 15:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@Xerox.COM,
CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19871029184314.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871029151550.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 29 Oct 87 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
I don't understand what you find insufficiently explicit about this now.
Do you mean that we should say
(defun (setf foo) ...) works like (defun foo ...)
(flet (((setf foo) ... works like (flet ((foo ...
(declare (inline (setf foo))) works like (declare (inline foo))
(symbol-function '(setf foo)) works like (symbol-function 'foo)
and so on for all the rest of them?
That seems pretty pointless to me. You must mean something more profound,
but I don't see what.
...
I don't think I meant anything drastically profound in any given case, but I
do think it's more important to do this enumeration than you're suggesting.
Many ``obvious'' things follow from the statements in your proposal, but some
of them may be surprising to some people, depending on how far their forward
chaining theorem prover runs when they read the descriptions you've provided.
And in a few cases, I bet we've not thought out all the consequences enough
to realize the subtle pitfalls that might follow...
* Some people will distrust their ability to extrapolate and be likely
to say to themselves: ``Surely they couldn't have meant that I should
write (SYMBOL-FUNCTION '(SETF FOO)).'' By stating this explicitly,
we'll confirm that this extrapolation is correct.
* Some people may expect that
(DEFUN (SETF FOO) (VAL) ...)
sets up (DOCUMENTATION '(SETF FOO) 'FUNCTION) while others may expect
that it sets up (DOCUMENTATION 'FOO 'SETF). Some may expect that
(DOCUMENTATION 'FOO 'SETF) is oboleted, while others may assume that
you now have to know how the SETF thing was defined in order to get
its documentation. Others may expect (DOCUMENTATION 'FOO 'SETF) to
apply only to SETF macros and (DOCUMENTATION '(SETF FOO) 'FUNCTION)
to apply to SETF functions, independently of how they're defined.
* Some people may wonder whether (FLET ((FOO ...)) ...) will implicitly
make (SETF FOO) lexically funbound. By writing things out in English,
we have a place where we can be explicit remarks about this. They may
be redundant with logical consequences of things you've already written,
but I think some such redundancy is appropriate in a proposal of this
kind.
* By the way, some people, myself included, have functions which map
down existing linguistic constructs such as declarations and do things
like GET on them because they presuppose that the things they're
operating on will be symbols. Since GET works only on symbols, such
code will be broken by this so-called upward compatible change. A more
subtle consequence is something which takes a function name and does
MEMBER into a list of function names. That won't blow out but unless
:TEST #'EQUAL is added, it will no longer reliably find the function name.
By mentioning things like (PROCLAIM '(INLINE (SETF FOO))) you may trigger
a red flag in some people's brains that alerts them to a potential
impact of this change which you had not anticipated.
* You need to specify things like how the implicit block in (SETF FOO)
generalizes. Does (RETURN-FROM (SETF FOO) ...) work, or does it just
create a (BLOCK FOO ...).
I could probably think of more of these. I think that by making a little paragraph
that claims to explain the extrapolation technique for each of these functions,
we will make it more likely that someone will notice other little nagging oversights
that need to be explicitly addressed. As long as you just say "and these will
be attended to in the obvious way" there is nothing to criticize/correct and yet
grave potential for loose ends to be left dangling.
∂29-Oct-87 2102 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Oct 87 21:02:09 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 267934; Fri 30-Oct-87 00:02:04 EST
Date: Fri, 30 Oct 87 00:01 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870922-125221-12440@Xerox>
Message-ID: <871030000121.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I think this takes care of the loose ends for APPEND-DOTTED.
* Added information about Kyoto CL and Xerox CL current practice.
* Added discussion of (APPEND '() T).
* Added parallel mention of NCONC.
-----
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman,
29-Oct-87, Version 2 by Pitman (loose ends)
Status: For Internal Discussion
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last list given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the
list to be returned.
In the degenerate case where there is no last cons (i.e., the argument
is NIL) in any but the last list argument, clarify that the entire argument
is effectively ignored. Point out that in this situation, if the last
argument is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Test Case:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Xerox Common Lisp and Kyoto Common Lisp signal errors when using APPEND
or NCONC on a dotted list.
Adoption Cost:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND or NCONC
incompatibly, the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow
things down.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and
NCONC can therefore produce dotted lists, some readers may have
(incorrectly) assumed that APPEND and NCONC can reliably deal in
general with dotted lists, something that doesn't appear to be guaranteed
by a strict reading. The proposed extension would happen to legitimize
such assumptions.
Conversion Cost:
This change is "upward compatible".
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between
lists and dotted lists. Those who view dotted lists as a special kind
of list may feel differently than those who view lists as a special
kind of dotted list.
Discussion:
Pitman supports the proposed extension.
∂29-Oct-87 2203 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 22:03:08 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 Oct 87 01:05:21-EST
Date: Fri, 30 Oct 1987 01:05 EST
Message-ID: <FAHLMAN.12346524608.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: APPEND-DOTTED (Version 2)
In-reply-to: Msg of 30 Oct 1987 00:01-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Looks fine to me.
∂30-Oct-87 0820 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 08:20:43 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Fri 30 Oct 87 08:17:14-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Fri, 30 Oct 87 08:19:03 PST
Received: from hplabsz.hpl.hp.com by hplms2; Fri, 30 Oct 87 08:18:25 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Fri, 30 Oct 87 09:17:54 pst
To: masinter.pa@xerox.com
Cc: fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu,
kempf%hplabs@hplabs.HP.COM
Subject: Issue: TRACE-FUNCTION-ONLY (Version 4)
X-Mailer: mh6.5
Date: Fri, 30 Oct 87 08:17:51 PST
Message-Id: <3685.562609071@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
(Font Note: UPPERCASE indicates bold, _this_ indicates italic)
--------------------------------------------------------------------------------
Issue: TRACE-CLOS
References: trace macro pp. 440-441
TRACE-ARGUMENT-FORMAT-OPTIONS
SETF-CLOS
Category: MODIFICATION
Edit history: Version 1, 21-Oct-87 Kempf
Version 2, 27-Oct-87 Kempf
Version 3, 28-Oct-87 Kempf
Version 4, 30-Oct-87 Kempf
Problem description:
With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of particular
methods to be traced, rather than invocation of the entire generic
function. In addition, the current specification of TRACE does not
allow tracing of functions associated with SETF "methods", of macro
functions, nor of lexically defined functions or functions invoked via. their
function definition objects. While this proposal does not attempt
to address the latter two problems, since identification and/or tracing of these
is likely to be implementation dependent, it does leave
open the option for those implementations which can arrange it.
Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)
TRACE _{function-spec}*_ _[Macro]_
UNTRACE _{function-spec}*_ _[Macro]_
Invoking TRACE with a function specification causes the function specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. UNTRACE undoes any tracing. Calling TRACE without
any arguments prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.
A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent; however,
every implementation is required to support the following:
_symbol_-Invocations of the function or macrofunction named by
_symbol_ via. _symbol_ as a global name are traced.
(METHOD _generic-function-name-specification_
_{method-qualifiers}_*
_parameter-specializer-name-list_
)
If the method whose parameter specializer list, generic function
name specification, and method qualifiers are listed is tracable,
then invocations through the generic function name specification
will be traced.
(SETF _symbol_)-If the SETF function having the name specification
is tracable, it will be traced (see proposal SETF-CLOS for
more information on SETF name specifications).
Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.
Note that this proposal does not change the current Common Lisp
specification in the area of "open-coded" functions. In particular,
implementations need not arrange for tracing of "open-coded" functions,
including compiled self calls which do not go through the symbol-function
cell.
In the case of tracing macro expansions, the trace is of the call to
the macroexpansion funtion and not of executing the return code. Thus the
trace function need only print the calling form arguments and the
expanded form being returned. As with "open-coded" functions, implementations
which memoize the expansion code are under no obligation to report trace
information once the macro code has been memoized. The example section
provides an example of an interactive session tracing a macro expansion.
Example:
1 [LISP] > (defmacro test-trace (arg)
1 [LISP] > `(format T "~S~%" ,arg)
1 [LISP] > )
TEST-TRACE
2 [LISP] > (trace test-trace)
((MACROFUNCTION TEST-TRACE))
3 [LISP] > (test-trace 'foo)
Entering macrofunction TEST-TRACE with arguments:
(QUOTE FOO)
Leaving macrofunction TEST-TRACE with return values:
(FORMAT T "~S~%" (QUOTE FOO))
FOO
4 [LISP] >
Rationale:
Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods. Adoption of the
SETF-CLOS proposal will require means of tracing SETF functions. It is
also not possible to easily trace either SETF functions or macrofunctions
today.
This proposal does not address a number of additional features of TRACE
(adding breakpoints, system hooks for extensible debugging, etc.) which
may be included in other proposals. In addition, the proposal recongnizes
that TRACE is part of the enviroment, and that future versions of the
Common Lisp standard may want to specify it as such. Different criteria
may therefore apply for evaluating compliance, for example, stand alone
Common Lisp applications may not require environmental features like
TRACE which are primarily included for program development, and their
compliance to the standard should therefore not be judged on the basis
of whether or not they implement such environmental features.
Current practice:
There is currently no way which is standard across all implementations
to trace SETF functions, aside from macroexpanding a SETF form and using
the resulting name in a TRACE macro invocation. There is currently no way
which is standardized across all implementations to trace macroexpansion
functions when they are invoked through their global names, except through
complicated use of *MACROEXPAND-HOOK*.
Adoption Cost:
The proposed syntax is upwardly compatible with the current Common Lisp
syntax. It will require the addition of function specification parsing
and wrapper code to trace SETF function executions and macrofunction
executions. When the Common Lisp Object System is fully implemented,
wrapper code for tracing method execution will also be required.
Cost of non-adoption:
Implementations will provide this functionality in varying forms and
to varying degrees, thus making it harder for users to move between
one Common Lisp system and another. Some implementations may choose
not to provide the functionality, in which case users will suffer.
Benefits:
Allow programmers to obtain information on individual method
invocations, and on SETF function and macrofunction invocations
in a uniform way across all implementations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
generating functions. Some implementations which have made extensions
to TRACE will need to accommodate those extensions with the additional
syntax.
∂30-Oct-87 0932 CL-Cleanup-mailer REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Oct 87 09:31:50 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 268368; Fri 30-Oct-87 12:32:42 EST
Date: Fri, 30 Oct 87 12:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871030123158.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
There has been no discussion on DLA's REMF-DESTRUCTION-UNSPECIFIED
proposal.
I apologize for the length of this proposal; I propose that only half of
it reach X3J13. We just have to figure out which half.
In certain ways, my feeling is that potential implementation speed is up
against debuggability here. There may be other ways of characterizing
the skew as well. If you mostly agree with one half but have minor
problems, please vote for that half and then propose changes to smooth
things out once we have things cut down to size. I think we should get a
general sense for how people want to proceed globally before doing a lot
of nitpicking.
-----
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION
Edit history: 11-Feb-87, Version 1 by DLA@Stony-Brook.SCRC.Symbolics.COM,
29-Oct-87, Version 2 by Pitman (flesh out proposals)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
In MAKE-EXPLICITLY-DEFINED, BAR would hold (C D E F).
In MAKE-EXPLICITLY-VAGUE, any of these interpretations (and
others as well) would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
In MAKE-EXPLICITLY-DEFINED, they would return (B C) and NIL.
In MAKE-EXPLICITLY-VAGUE, either of these interpretations (and others
as well) would be valid.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED):
Clarify that the destructive behavior of the following operators
is restricted as indicated. Note well -- only the side-effect behavior
of these functions is discussed here; these remarks are not intended
as complete functional descriptions.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF the CADR of what
(GET-PROPERTIES place (LIST indicator)) would return.
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In particular, the two removed cells may not be destructively
modified.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list is permitted to setf the CDR of any
subtail of sequence to point to any other subtail of sequence,
to NIL, or to any piece of newly created list structure.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a tail whose car is object.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a duplicated element that is to be
removed.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list is permitted to SETF the CAR of any part
of that list which must be replaced by NEW-OBJECT.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF the CDR of the LAST of any of its argument
lists which are non-null, except the last argument.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF the tail of its argument list whose CDR
is LAST of that argument LIST.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to setf the CDR of any subtail of either list to point
to any other subtail of either list, to NIL, or to any piece of newly
created list structure.
Rationale:
This implements what some users will consider the status quo.
In most cases, it is consistent with what naive implementations of
these functions might do.
Benefits:
By being more explicit about the side-effects which can be expected,
users can write programs which more reliably exploit these side-effects.
In some case, this may make certain programming problems easier.
Certain naive user assumptions and assumptions based on the behavior
of older lisp dialects would be supported.
Compatibility with older Lisp dialects (eg, Zetalisp, Maclisp, ...)
would generally be better.
Gratuitious porting hassles would be naturally lessened slightly.
In situations where programmers inadvertently depended upon the specific
nature of a particular operator's side-effect, chances would be much
greater that the code would be portable because there would be less room
for implementations to vary.
Non-Benefits:
Implementations may be forced to be less efficient than they could be
if the MAKE-EXPLICITLY-VAGUE proposal were adopted, since that proposal
allows implementors more room for optimization. Some existing
implementations will be forced to become less efficient to meet the
standard, degrading performance of existing applications which do not
rely on the new features with no benefit to those existing applications.
Adoption Cost:
Some implementations would have to change. For example, Symbolics Common
Lisp makes more unusual assumptions about what it can modify than some
of the above rules allow.
Conversion Cost:
Probably none. Users must currently tread lightly since they really
have no idea in many cases what kind of side-effect is really likely to
occur when they use some of the existing destructive operators.
Some implementations might be forced to change, and since some user
programs might have depended on the old behavior, programs which used
to run might be broken in the transition. However, in most cases where
an implementation guarantees any behavior, it is likely to be the one
suggested here. Systems which have other behaviors are likely to warn
users not to depend on the specifics of those behaviors. So the incidence
of problems arising in practice is likely to be very small, though
probably not nonzero.
Aesthetics:
Some of these restrictions tend to expose more detail about the
implementation of these operators, turning them from abstract operations
into more concrete utilities. This is probably an issue that can be
addressed by appropriate information hiding in a User's Manual however.
No matter how unpleasant the presence of these somewhat concrete
restrictions may seem, the porting bugs which arise in their absence are
bound to seem more unpleasant to some users.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE):
Clarify that the destructive behavior of the following operators
is restricted as indicated:
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Rationale:
This is probably the status quo from a typical implementor's point of view.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Adoption Cost:
None. This is the status quo for implementors.
Conversion Cost:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Conversation on the Common-Lisp mailing list has made it clear that
the current situation is not good because it does not make the designers'
intent clear. The list modification allowed should either be specified,
or explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
Pitman believes that REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE
may be better from a purist point of view, but strongly supports
REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED
because of practical considerations related to reliably being able to
debug portable code, a stated priority of an ``industrial strength''
language such as Common Lisp. The more alike implementations are forced
to be, the better the chances that something that ran one place will run
another.
DLA, who raised this issue, disagrees strongly. He cites efficiency
and does not believe performance should be traded off for features
which reasonable code does not tend to use. Metering in Symbolics test
systems have shown that there are performance gains to be had by
allowing implementations flexibility in these areas. DLA believes that
if users want more predictability from these functions, they should
write private variants that implement whatever predictability they
require. Additionally, he argues that the implementation users expect
is not obviously the one chosen in MAKE-EXPLICITLY-DEFINED. For
example, many programmers have used NREVERSE for years and assumed that
it shuffled list elements rather than CDRs.
DLA points out that MAKE-EXPLICITLY-DEFINED is still lax enough that if
FOO holds (A B) and you do (SETF (GETF FOO 'A) 'C), FOO could be
(A C A B). We should be sure this doesn't get left vague if that
proposal is adopted.
∂30-Oct-87 1117 CL-Cleanup-mailer Re: APPEND-DOTTED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Oct 87 11:16:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 OCT 87 11:17:16 PST
Date: 30 Oct 87 11:16 PST
From: Daniels.pa@Xerox.COM
Subject: Re: APPEND-DOTTED (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 30 Oct 87 00:01 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871030-111716-5825@Xerox>
Looks OK.
-- Andy. --
∂30-Oct-87 1150 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Oct 87 11:50:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 OCT 87 11:49:30 PST
Date: 30 Oct 87 11:49 PST
From: Masinter.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 30 Oct 87 12:31 EST
To: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871030-114930-5868@Xerox>
I am in favor of making the behavior of CL as well specified as
possible. I also think that users should be discouraged from taking
advantage of subtle details. I don't think the two are incompatible; one
is a matter of portability and more complete programming language
semantics, and the other is a matter of good programming practice.
For example, I think it might be reasonable for *compilers* to take
advantage of the explicitness of the language semantics, even if *users*
are encoraged to avoid doing so. For example, it might well be useful to
know that (setf (getf a b) c) and (car x) are order independent
operations; this can be deduced if (SETF (GETF ...) ...) is constrained
only to have CDR-class side-effects.
The performance argument given is pretty weak. Perhaps the right
solution for DLA would be to have a SCL:NREVERSE which had the desired
(undefined) side-effect behavior? To be taken seriously, I'd like to
hear some actual statistics, e.g., is there any evidence that this would
make more than a 5% difference in total runtime in any implementation
for any benchmark?
(I've been trying to come up with a better way of phrasing the side
effect behavior. I think I'd be happier with an alternative to
"permitted to SETF" and "constrained"; maybe just "will only affect"
.... I know that several theses have been written on characterization of
side-effect behavior in Lisp programs, and it might be just as well for
a formal specification of CL to make reference to a more formal
terminology.)
∂30-Oct-87 1154 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Oct 87 11:54:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 OCT 87 11:54:02 PST
Date: 30 Oct 87 11:53 PST
From: Masinter.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 30 Oct 87 12:31 EST
To: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871030-115402-5874@Xerox>
I realized after I hit the Deliver button that the argument I made for
compilers taking advantage of side-effect information is not relevant:
after all, of course any (implementation specific) compiler can make
implementation-specific assumptions. While I can imagine
implementation-specific code analyzers, optimizers, and the like, it
isn't quite as compelling.
∂30-Oct-87 1206 CL-Cleanup-mailer APPEND-DOTTED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Oct 87 12:06:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 268580; Fri 30-Oct-87 15:07:12 EST
Date: Fri, 30 Oct 87 15:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871030000121.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871030200707.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Looks fine to me.
∂30-Oct-87 1307 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Oct 87 13:07:33 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 OCT 87 13:08:21 PST
Date: Fri, 30 Oct 87 13:08:16 PST
From: Pavel.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: <871030-114930-5868@Xerox>
To: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871030-130821-5980@Xerox>
I strongly support MAKE-EXPLICITLY-VAGUE or something even vaguer. I
really dislike the idea of programs that count on the subtle behavior of
such abstract constructs. Also, I don't believe that we can define the
side-effect behavior sufficiently well to help someone be gross in this
way without actually writing the code to implement the functions and
publishing that standard implementation.
For all of these reasons, I am strongly against MAKE-EXPLICITLY-DEFINED.
Pavel
∂30-Oct-87 1854 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 18:54:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 Oct 87 21:56:08-EST
Date: Fri, 30 Oct 1987 21:56 EST
Message-ID: <FAHLMAN.12346752309.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabs@HPLABS.HP.COM
Subject: Issue: TRACE-FUNCTION-ONLY (Version 4)
In-reply-to: Msg of 30 Oct 1987 11:17-EST from kempf%hplabsz at hplabs.HP.COM
OK, I can support this now. Thanks for putting in those changes.
-- Scott
∂30-Oct-87 1917 CL-Cleanup-mailer REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 19:17:03 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 Oct 87 22:19:10-EST
Date: Fri, 30 Oct 1987 22:19 EST
Message-ID: <FAHLMAN.12346756507.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: Msg of 30 Oct 1987 12:31-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I've wavered back and forth a few times on this in last hour, but I seem
to be converging toward MAKE-EXPLICITLY-VAGUE.
I argued before that it was treacherous, if not clearly illegal, for
implementations to play around with list cells in unexpected ways. Most
users will have a naive model of what is going on, more or less
equivalent to what is described in MAKE-EXPLICITLY-DEFINED, and it is
likely to screw these users in very subtle ways to go in and manipulate
the cells in some toher way that happens to make CDR-coding happy. But
if we give the users a sufficiently clear warning that they can't count
on the naive model, then I think it's acceptable to allow implementors
this freedom.
However, we should only go with MAKE-EXPLICITLY-VAGUE if the CDR-coding
people really think it is going to make a significant difference in the
efficiency of some real programs. I tend to doubt this, but I haven't
played much with CDR-coding and I'll yield to those with more
experience. If the added freedom only is going to make a tiny
difference, we should go with MAKE-EXPLICITLY-DEFINED, and give the
poor users one less confusing trap to fall into.
-- Scott
∂31-Oct-87 1653 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Oct 87 16:53:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 87 16:51:17 PST
Date: 31 Oct 87 16:50 PST
From: Masinter.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
30 Oct 87 22:19 EST
To: CL-Cleanup@SAIL.STANFORD.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871031-165117-6815@Xerox>
Frankly, I'm not particularly willing to adopt MAKE-EXPLICITLY-VAGUE on
the basis of mere speculation that this might allow some performance
improvements. The example of using %CHANGE-LIST-TO-CONS rather than
RPLACD is given, but no guidelines as to how important that could
possibly be. I have a hard time imagining that there is any program,
real or artificial, that the MAKE-EXPLICITLY-VAGUE will make more than
trivially faster. Here's my best shot at imagining one: suppose you
constructed a cdr-coded list, did DELETE on every other element using
RPLACD instead of %CHANGE-LIST-TO-CONS, and then CDR'd down it lots.
Would it run more than 5% more slowly? Wouldn't the next GC remove the
forwarding pointers?
At the risk of repeating myself, be careful to avoid confusing good
programming practice with good programming language design. Whether
users *should* write programs which depend upon exact specifications is
a style issue.
I'm confused about Pitman's assertion that a purist would prefer
MAKE-EXPLICITLY-VAGUE. Which kind of purity? I can't imagine any part of
the programming task that MAKE-EXPLICITLY-VAGUE would make more
convenient, easier, more facile, less error-prone.
I'd agree that we have to tighten up MAKE-EXPLICITLY-DEFINED to really
make portability possible.
I don't think the Benefits given for MAKE-EXPLICITLY-DEFINED are what I
would write; I think the major benefit is in portability of debugged
programs. I don't think it is much of a benefit that users CAN write
programs which exploit them; rather, for those who must deal with
programs where the original programmers DID exploit them, the programs
will be more portable.
If I had to, I would rank order these in the order of importance for
specificity. For example, it seems more important to give NCONCs
behavior as specified than it does to give NREVERSE.
∂02-Nov-87 1241 CL-Cleanup-mailer visit, Professor Takayasu Ito
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Nov 87 12:41:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 NOV 87 12:40:48 PST
Date: 2 Nov 87 12:40 PST
From: Masinter.pa@Xerox.COM
Subject: visit, Professor Takayasu Ito
To: cl-cleanup@sail.stanford.edu
Message-ID: <871102-124048-1490@Xerox>
Prof. Ito is the chairman of the JEIDA Committee for Lisp
Standardization. He is the one who sent out a message a while back. He
was in town and we got together yesterday; I gave him the current list
of topics under consideration, and a couple of samples. I marked the
copies as DRAFT - UNDER DISCUSSION.
He said they had a list of 50 problems/issues in CL that their group had
come up with... I expect we will get these from them at some point.
∂02-Nov-87 1714 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 2 Nov 87 17:14:28 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139052; Mon 2-Nov-87 19:43:57 EST
Date: Mon, 2 Nov 87 19:43 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM, KMP@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <871030-114930-5868@Xerox>,
<871030-115402-5874@Xerox>,
<871031-165117-6815@Xerox>
Message-ID: <19871103004347.9.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 30 Oct 87 11:49 PST
From: Masinter.pa@Xerox.COM
I am in favor of making the behavior of CL as well specified as
possible. I also think that users should be discouraged from taking
advantage of subtle details. I don't think the two are incompatible; one
is a matter of portability and more complete programming language
semantics, and the other is a matter of good programming practice.
Here we are in agreement. I don't think anything you said is
incompatible with MAKE-EXPLICITLY-VAGUE; the key here is explicit. We
should make the language explicit so users know what to expect.
Certainly both alternatives are better than the present situation.
[You already said what I was going to say about compiler optimizers, so
I deleted it.]
The performance argument given is pretty weak. Perhaps the right
solution for DLA would be to have a SCL:NREVERSE which had the desired
(undefined) side-effect behavior? To be taken seriously, I'd like to
hear some actual statistics, e.g., is there any evidence that this would
make more than a 5% difference in total runtime in any implementation
for any benchmark?
You're making the mistake of assuming that all performance effects can
be measured by runtimes, and that you can use a threshold on whatever
that is to make a decision. Runtimes are important for benchmarks, but
working-set overhead, garbage-collector overhead, and secondary effects
due to noncollection of garbage usually dominate for large applications.
I hope I am not taking a leap of faith in assuming that Common Lisp is
intended to be used for real applications.
There are some particular elements of the MAKE-EXPLICITLY-VAGUE proposal
which I feel strongly about: REMF, NREVERSE, and DELETE. Of course,
arguments on one function extend naturally to the family of functions
with the same behavior.
REMF: We have measured substantial *space* improvements in large
systems by making REMF (and REMPROP) replace the pointer to the removed
property with NIL. Thus we make (REMF a b) roughly equivalent to
(PROGN (SETF (GETF a b) NIL) (REMF a b)). This yields substantially
better garbage-collector performance because the garbage collector can
immediately reclaim the property without reclaiming the list first.
Especially if the property list is connected with a symbol, it can be
quite a bit older. More reclaimed garbage means less total space used
by user structures, less frequent garbage collections, and more locality
of reference.
REMF (weaker): In the Symbolics implementation, cdr-coded list blocks
are reclaimed or kept only in their entirety. For example,
(LAST (MAKE-LIST 1000)) takes up 1000 cells, even if you only have a
pointer to the last cell. For cdr-coded property lists, this means that
a the REMF'd portion of the property list may never get reclaimed. To
solve this, we further change REMF so it is roughly equivalent to
(PROGN (MULTIPLE-VALUE-BIND (IGNORE IGNORE TAIL)
(GET-PROPERTIES a (LIST b))
(WHEN TAIL
(SETF (CADR TAIL) NIL) ;This is what we did in the last paragraph.
(SETF (CDDR TAIL) NIL))) ;This allows the removed conses to be reclaimed.
(REMF a b))
NREVERSE: Fast, linear algorithms exist for reversing lists by
shuffling elements, by shuffling conses, or by a combination of those
two strategies. I believe individual implementations should be allowed
to choose the implementation which is faster for them.
NREVERSE (weaker): In implementations with cdr-coded lists, a
significant performance degradation would be introduced if NREVERSE were
forced to be implemented with RPLACD. The speed difference alone on a
cdr-coded list could make this argument, and additional GC overhead (to
reclaim the original conses) and working-set overhead (to accommodate the
resulting non-coded list) makes it worse. I could get exact numbers
for you if you want, but on the Symbolics implementation, the speedup is
at least 3:1.
DELETE: KMP mentioned this in his proposal because it is an example
where cdr-coded implementations can use %CHANGE-LIST-TO-CONS rather than
RPLACD. Once again, %CHANGE-LIST-TO-CONS is simply two memory
references, while a RPLACD of a cdr-coded list can take many times that
amount of time, escaping from microcode to run the macrocode escape
routine, updating the cons caches, allocating pages, and GC scavenging.
Whether this makes a 1% difference or a 1000% difference in your program
depends on how cdr-coded your list is, how paging-bound your application
is, how long your list is, and how many elements in the list will be
deleted.
On the subject of compilers, it is practically impossible to implement
any of the features above based on compile-time analysis. When
compiling a function, you have to have complete lexical knowledge of the
creation, usage, and creation of pointers to a list before such an
optimization is useful. For the above functions, this would cause
the compiler optimizers to be fairly worthless.
Date: 31 Oct 87 16:50 PST
From: Masinter.pa@Xerox.COM
Frankly, I'm not particularly willing to adopt MAKE-EXPLICITLY-VAGUE on
the basis of mere speculation that this might allow some performance
improvements. The example of using %CHANGE-LIST-TO-CONS rather than
RPLACD is given, but no guidelines as to how important that could
possibly be. I have a hard time imagining that there is any program,
real or artificial, that the MAKE-EXPLICITLY-VAGUE will make more than
trivially faster. Here's my best shot at imagining one: suppose you
constructed a cdr-coded list, did DELETE on every other element using
RPLACD instead of %CHANGE-LIST-TO-CONS, and then CDR'd down it lots.
Would it run more than 5% more slowly? Wouldn't the next GC remove the
forwarding pointers?
This is NOT mere speculation, and I resent your calling it that. I would
not be proposing this if it were frivolous.
In your example, DELETE would take approximately 4.5 times as long as it
otherwise would. This is without taking into account any GC or paging
effects. The amount of time it would take to subsequently walk the list
would be little affected. The next GC would indeed remove forwarding
pointers. However there is additional overhead because GC will be
forced to run sooner. See the appendix to this message.
At the risk of repeating myself, be careful to avoid confusing good
programming practice with good programming language design. Whether
users *should* write programs which depend upon exact specifications is
a style issue.
I'm confused about Pitman's assertion that a purist would prefer
MAKE-EXPLICITLY-VAGUE. Which kind of purity? I can't imagine any part of
the programming task that MAKE-EXPLICITLY-VAGUE would make more
convenient, easier, more facile, less error-prone.
I prefer MAKE-EXPLICITLY-VAGUE, although some of the vagueness KMP has
come up with I believe is unnecessary. I believe what he meant was that
a purist would argue that this forces the programmer to respect a
certain level of abstraction. (I only speculate because KMP has not
responded.)
I don't think the Benefits given for MAKE-EXPLICITLY-DEFINED are what I
would write; I think the major benefit is in portability of debugged
programs.
I agree. However, as I pointed out to KMP privately, my experience has
been that programs have much more difficulty being ported due to their
doing things something which "is an error", and only one of the two
implementations actually signal an error. The only times I have seen
problems converting code based on these assumptions is when converting
old MACLISP programs which use the then-documented side-effects.
I don't think it is much of a benefit that users CAN write
programs which exploit them; rather, for those who must deal with
programs where the original programmers DID exploit them, the programs
will be more portable.
If I had to, I would rank order these in the order of importance for
specificity. For example, it seems more important to give NCONCs
behavior as specified than it does to give NREVERSE.
I agree, sort of. I can imagine an implementation of NCONC which used
%CHANGE-LIST-TO-CONS on the tail of the first list if it were cdr-coded,
then explicitly created a CONS for the missing element. This wouldn't
buy anything in our implementation, but it's conceivable it might in
others.
In closing:
There are many instances why substantial performance improvements have
been realized by techniques allowed under MAKE-EXPLICITLY-VAGUE. Many
of these improvements have been part of Symbolics Common Lisp for many
years, and I am unaware of any bug reports relating to them, which tends
to support the claim that users don't use undocumented side-effects.
On the other hand, oftentimes people with large applications are stumped
as to why their application, which benchmarked well during testing, has
gotten so slow on real problems. Or they wonder why they can't collect
any garbage on their machines even though they have removed all pointers
to their objects. Such things are quite difficult for the uninitiated
to track down. When I tell them, say, to do
(PROGN (SETF (GETF a b) NIL) (REMF a b)) instead of (REMF a b), it only
incites them to complain that Common Lisp is a language only
implementors can understand.
Appendix
(DEFUN MASINTER-DELETE (ELEMENT LIST)
(LET ((TOP (LOCF LIST))) ;The (LOCF LIST) could be (CONS NIL LIST) for portability.
(DO ((L LIST (CDR L))
(PREVIOUS TOP L))
((ENDP L)
(CDR TOP))
(DO ()
((NOT (EQL (CAR L) ELEMENT)))
(SETF (CDR PREVIOUS) (CDR L))
(SETQ L (CDR L))
(WHEN (ENDP L)
(RETURN-FROM MASINTER-DELETE (CDR TOP)))))))
Running this on a list, 1000 long, of alternating A and B. This timing
excludes most paging and GC effects, which would tend to dominate in
larger programs. Symbolics 3640, In-House development software.
MASINTER-DELETE A took 0.07725 seconds
MASINTER-DELETE B took 0.070475 seconds
DELETE A took 0.017822 seconds
DELETE B took 0.017825 seconds
MASINTER-DELETE A took 0.077003 seconds
MASINTER-DELETE B took 0.076675 seconds
DELETE A took 0.017718 seconds
DELETE B took 0.017838 seconds
MASINTER-DELETE A took 0.078764 seconds
MASINTER-DELETE B took 0.07683 seconds
DELETE A took 0.017821 seconds
DELETE B took 0.017826 seconds
∂02-Nov-87 1918 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Nov 87 19:17:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 NOV 87 18:22:43 PST
Date: 2 Nov 87 18:22 PST
From: Masinter.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>'s message
of Mon, 2 Nov 87 19:43 EST
To: DLA@DIAMOND.S4CC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871102-182243-2120@Xerox>
No offense was intended in my message. I think that you have provided
some data which will help give a much stronger justification for
MAKE-EXPLICITLY-VAGUE.
For example, I was unaware of the behavior of the Symbolics GC on
cdr-coded list blocks. I didn't imagine that the difference on DELETE
would be nearly as high as you measured. I think the proposal might
say something like "For example, in one implementation, the best
implementation of DELETE under MAKE-EXPLICITLY-VAGUE is over four times
faster than the simple implementation using RPLACD." The interaction
with ephemeral garbage collection is useful to document.
However, in reviewing the language in CLtL surrounding these destructive
functions, I think that it is pretty explicit about some.
For the functions DELETE, DELETE-IF, DELETE-IF-NOT, NREVERSE, SORT,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT,
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR it says "This is a destructive
operation. The argument sequence may be destroyed and used to construct
the result." so smashing either the CARs or CDRs randomly seems OK.
But most of the other functions side-effect behavior is much more
explicitly described in CLtL; I can't imagine anyone in the user
community seeing it as a step forward to make these any more vague than
they already are.
CLtL is pretty explicit about what (SETF (GETF ..) ..) does (it adds a
new pair or modifies the old), REMF (it splices out the conses),
REMPROP, NRECONC, NBUTLAST. It might be OK to also smash the CAR of the
list being spliced out with REMF.
NSUBST it says "the list structure of tree is altered by destructively
replacing with new each leaf or subtree of the tree such that old and
the leaf or subtree satisfy the test".
CLtL is also very explicit about NCONC.
I know that I have frequently written (NCONC place Y) where I can assert
that place is CONSP, assuming this is equivalent to (SETF (CDR (LAST
place)) Y). I've also written code that assumes that (SETF (GETF place
'Y) z) behaves the same as (let((plist place)) (setf (getf plist 'y)
z)) when place has a y property, i.e., that this really only changes the
CAR in the case that the property was already there.
So, I think explicitly-vague NSUBST, NSUBST-IF, NCONC, NBUTLAST are far
less useful in the language; making them vague would be a serious
backward incompatibility for no substantial benefit.
∂02-Nov-87 1953 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 2 Nov 87 19:53:08 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 139085; 2 Nov 87 22:53:08 EST
Date: Mon, 2 Nov 87 22:52 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <871102-182243-2120@Xerox>
Message-ID: <19871103035217.7.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 2 Nov 87 18:22 PST
From: Masinter.pa@Xerox.COM
No offense was intended in my message. I think that you have provided
some data which will help give a much stronger justification for
MAKE-EXPLICITLY-VAGUE.
No offense taken, of course. Especially since, according to this
message, we seem to agree on practically everything!
For example, I was unaware of the behavior of the Symbolics GC on
cdr-coded list blocks. I didn't imagine that the difference on DELETE
would be nearly as high as you measured. I think the proposal might
say something like "For example, in one implementation, the best
implementation of DELETE under MAKE-EXPLICITLY-VAGUE is over four times
faster than the simple implementation using RPLACD." The interaction
with ephemeral garbage collection is useful to document.
However, in reviewing the language in CLtL surrounding these destructive
functions, I think that it is pretty explicit about some.
For the functions DELETE, DELETE-IF, DELETE-IF-NOT, NREVERSE, SORT,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT,
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR it says "This is a destructive
operation. The argument sequence may be destroyed and used to construct
the result." so smashing either the CARs or CDRs randomly seems OK.
But most of the other functions side-effect behavior is much more
explicitly described in CLtL; I can't imagine anyone in the user
community seeing it as a step forward to make these any more vague than
they already are.
CLtL is pretty explicit about what (SETF (GETF ..) ..) does (it adds a
new pair or modifies the old), REMF (it splices out the conses),
REMPROP, NRECONC, NBUTLAST. It might be OK to also smash the CAR of the
list being spliced out with REMF.
I agree that SETF-GETF need not be changed.
It doesn't say how REMF (or REMPROP) splices out the conses, and it
doesn't define splicing to exclude splicing out both the pointer into
the pair and the pointer out of the pair.
I don't believe that NRECONC is specified any more than NREVERSE in the
current description. I believe that what goes for NREVERSE should apply
to NRECONC as well. (Indeed, in the Symbolics implementation NREVERSE
is implemented with NRECONC.)
I agree that there could be no use in vagueifying NBUTLAST. Probably
the reason it's included is because it was on my list of
list-destructing functions which I made by searching through CLtL in 3
minutes.
NSUBST it says "the list structure of tree is altered by destructively
replacing with new each leaf or subtree of the tree such that old and
the leaf or subtree satisfy the test".
Fine.
CLtL is also very explicit about NCONC.
I know that I have frequently written (NCONC place Y) where I can assert
that place is CONSP, assuming this is equivalent to (SETF (CDR (LAST
place)) Y). I've also written code that assumes that (SETF (GETF place
'Y) z) behaves the same as (let((plist place)) (setf (getf plist 'y)
z)) when place has a y property, i.e., that this really only changes the
CAR in the case that the property was already there.
Fine.
So, I think explicitly-vague NSUBST, NSUBST-IF, NCONC, NBUTLAST are far
less useful in the language; making them vague would be a serious
backward incompatibility for no substantial benefit.
I can agree to this. NCONC is fuzzier than the rest, but since there is
no clear advantage to making the specification vague we probably
shouldn't do it.
∂03-Nov-87 0859 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 87 08:59:07 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 NOV 87 08:59:58 PST
Date: 3 Nov 87 08:59 PST
From: Brotsky.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: Masinter.pa's message of 2 Nov 87 18:22 PST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871103-085958-2800@Xerox>
With respect to SETF-GETF and REMF, I strongly support
MAKE-EXPLICITLY-VAGUE. CLtL says about using SETF with GETF:
... The effect is to add a new property-value pair, or update an
existing pair, in the property list kept in the place. ...
It's hard for me to see how, as Larry phrases it, this is ``pretty
explicit'' about what SETF-GETF is supposed to do. After all, it says
nothing about order of the pairs on the list before and after the
operation, or even that the same list is to be ``kept in the place''
before and after the operation. With respect to REMF, CLtL says:
... The property indicator and the corresponding value are removed
by destructively splicing the property list ...
This seems clearer at first glance: the obvious interpretation is that
in (REMF place) the plist in left in place after the REMF is EQ to the
plist in place when given to REMF. But of course if the pair to be
removed is the first pair in the list, then we'll have to do
``splicing'' by shifting CARs forward in the list. Actually I think
this language was left over from the discussion of REMPROP, but the
discussion of symbol-plists explicitly mentions that ``modifications to
the property list can be recorded by storing back into the property-list
cell of the symbol.'' So I tend interpret this as saying that the lists
in place before and after (REMF place) need not be EQ, but then it's not
clear if ANY restrictions are being place on REMF other than that the
indicator should not be present in the list when REMF is finished.
In general, I take it from the first and second paragraphs of page 164
that symbol plists and plists referenced with GETF and REMF are intended
to be dealt with in exactly the same way; after all, both types are just
``a memory cell containing a list with an even number (possibly zero) of
elements.'' Further, I see absolutely no restrictions across
list-modifying calls on the order of the pairs in plists, and I think
this is explicitly a data abstraction issue: after a destructive
operation on a plist is performed, you are guaranteed only that the
property list as ``an object with a unique identity'' (p. 164) is
preserved; that is, the memory cell associated with the plist contains a
list of pairs of the right form, but you are guaranteed nothing about
the relationship between that list of pairs and any preceeding lists
that used to be associated with that memory cell.
Consider, for example, a system (such as a program analysis tool) which
stores massive amounts of information (such as who-calls and other usage
info) on the plists of symbols. This system knows that, of the 300
properties it stores on symbols, it goes through phases (when it's
analyzing a particular function) of referencing only 5 or 6 of them
(relevant to that function) at a time. It also knows that, whenever
it's about to go into one of these phases, it sets the value of those
properties to some appropriate thing (such as info about the function
being analyzed). From reading CLtL, I see absolutely no reason why that
system should not be able to redefine SETF-GETF (or SETF-GET) so that a
stored property is always at the front of the resulting plist.
While I am sensitive to concerns about portability of debugged programs,
I think that, with respect to property lists, programmers who expect
behavior from SETF-GETF which accords with manipulations they perform on
the same lists are breaking the plist data abstraction. They are
implicitly doing what someone (Pavel?) earlier in this discussion
suggested MAKE-EXPLICITLY-DEFINED for SETF-GETF would be tantamount to
doing: insisting that SETF-GETF be implemented using a particular
algorithm.
dan
∂03-Nov-87 1106 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Nov 87 11:06:36 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 270848; Tue 3-Nov-87 14:06:35 EST
Date: Tue, 3 Nov 87 14:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Brotsky.PA@Xerox.COM, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <871103-085958-2800@Xerox>
Message-ID: <871103140614.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I think we must say explicitly whether (SETF GET) and (SETF GETF) are
permitted to re-order cells. Secondarily, I also think that we should
say that re-ordering is not permitted.
Among other things... You can do:
(SETQ X '(A B C D))
(SETF (GETF X 'C) 'E)
and indeed you don't have to worry whether
X => (A B C E) or (C E A B) or (C E A B C D)
if all you're going to do is
(GETF X 'C).
However, you must be much more careful about
(GET-PROPERTIES X '(A C))
which will then get
A, B, (A B C E)
or C, E, (C E A B)
or C, E, (C E A B C D)
depending on which strategy has been used.
The presence of an operator like GET-PROPERTIES in the language
acknowledges the fact that property list as we have come to use it is
not just an abstract table as some would have it be, but in fact an
ordered entry capable of doing a restartable multiple lookup. In my
view, this invites (almost begs) the user to exploit shadowing or
prioritizing. If (SETF GETF) is permitted to alter an existing ordering,
I believe that many programs which use GET-PROPERTIES will be
gratuitously broken.
It's easy to imagine writing programs which rely on the kind of side-effect
behavior I'm describing without realizing that you're doing so. If your
test cases happen not to show up the problem, it can be a real surprise
when you port. If you're lucky, things will just blow out, but often
they don't and you travel miles from the point of the error before you
notice something is wrong.
Leaving things unspecified may be nice for each individual implementation
but can be a real barrier to portability as I've learned from hard
experience with trying to get Macsyma to port.
I'm sympathetic to DLA's desire to optimize and I don't want to
trivialize the cost I'm asking him (and others) to pay. But not all of
language design can be based on worry over potentially lost optimizations.
If we thought that, we'd have said it was ok for
(+ (THE FIXNUM X) (THE FIXNUM Y))
to optimize into a fixnum add instruction. The current definition of
the language practically precludes the fixnum add instruction ever being
generated because the user is almost always (in my experience) too lazy
or otherwise unwilling to write
(THE FIXNUM (+ (THE FIXNUM X) (THE FIXNUM Y))).
The stock hardware people had to take a real performance hit on this one.
I haven't looked at the Gabriel benchmarks recently; perhaps it's kind
enough to provide a few benchmarks that suggest that people would really
write this kind of code, so perhaps it gives the impression that the
compiler can generate better code than I bet it typically does, so perhaps
it hasn't hurt the stock hardware people's sales so much. Who knows?
But in any case, the effective performance hit was the price we as a
community paid because we wanted things to port without surprises and
even though you could test your programs at the fixnum boundary points
on one machine with a particular word size, you couldn't easily anticipate
the effect of varying word sizes.
I consider the case of the destructive operations at least as important
as fixnum addition. Perhaps more so because I bet we are on the brink of
places where side-effects will bite us lots more often than we are on the
brink of places where machine word overflow will bite us.
Many CL users maintain code at one site in one or two implementations
and still want to share that code with others at other sites. The ability
to reliably debug portable code in a small number of implementations is
of key importance to those users.
I often feel like vendors want to put such portability issues at an
artificially low level. They mostly seem to want to be able to
(a) optimize the hell out of their implementation
and (b) leave enough vagueness in the spec that people will
find it painful to move out of their implementation into
someone else's. (Always in this an assumption that "the user"
begins in their own implementation and not in someone else's. :-)
∂03-Nov-87 1315 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 3 Nov 87 13:14:49 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141310; Tue 3-Nov-87 16:01:22 EST
Date: Tue, 3 Nov 87 16:00 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Brotsky.PA@Xerox.COM
In-Reply-To: <871103140614.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871103210016.9.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 3 Nov 87 14:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I think we must say explicitly whether (SETF GET) and (SETF GETF) are
permitted to re-order cells. Secondarily, I also think that we should
say that re-ordering is not permitted.
Ah, yes. I had forgotten about this. Believe it or not, I agree with
you. My reasons are:
(1) I have looked at reordering property lists to optimize programs, and
have determined that for most programs the reordering property lists
will have a negligible effect. Additionally, for those programs where
it may have an effect, usually the first thing a programmer will do is
replace the property list with a more appropriate abstraction such as a
hash table.
(2) Even if some implementation were to find that they could get a speed
improvement from, say, reordering properties on symbols, your proposal
does not preclude explicit actions, such as the "Optimize World" command
on Symbolics machines, from reordering property lists.
...
I'm sympathetic to DLA's desire to optimize and I don't want to
trivialize the cost I'm asking him (and others) to pay. But not all of
language design can be based on worry over potentially lost optimizations.
If we thought that, we'd have said it was ok for
(+ (THE FIXNUM X) (THE FIXNUM Y))
to optimize into a fixnum add instruction. The current definition of
the language practically precludes the fixnum add instruction ever being
generated because the user is almost always (in my experience) too lazy
or otherwise unwilling to write
(THE FIXNUM (+ (THE FIXNUM X) (THE FIXNUM Y))).
The stock hardware people had to take a real performance hit on this one.
I haven't looked at the Gabriel benchmarks recently; perhaps it's kind
enough to provide a few benchmarks that suggest that people would really
write this kind of code, so perhaps it gives the impression that the
compiler can generate better code than I bet it typically does, so perhaps
it hasn't hurt the stock hardware people's sales so much. Who knows?
But in any case, the effective performance hit was the price we as a
community paid because we wanted things to port without surprises and
even though you could test your programs at the fixnum boundary points
on one machine with a particular word size, you couldn't easily anticipate
the effect of varying word sizes.
I consider the case of the destructive operations at least as important
as fixnum addition. Perhaps more so because I bet we are on the brink of
places where side-effects will bite us lots more often than we are on the
brink of places where machine word overflow will bite us.
Many CL users maintain code at one site in one or two implementations
and still want to share that code with others at other sites. The ability
to reliably debug portable code in a small number of implementations is
of key importance to those users.
I often feel like vendors want to put such portability issues at an
artificially low level. They mostly seem to want to be able to
(a) optimize the hell out of their implementation
and (b) leave enough vagueness in the spec that people will
find it painful to move out of their implementation into
someone else's. (Always in this an assumption that "the user"
begins in their own implementation and not in someone else's. :-)
An interesting essay. I'm not sure I understand it all after a couple
readings, but I'll take a stab at responding.
As for the specific problems of not being able to optimize into a fixnum
add instruction, I'm hopeful that compiler and metering technology will
improve sufficiently to make it easier to optimize and port CL code. In
thie category of compiler and metering technology I include programs
which assist users in adding declarations to their code which will
improve performance based on code analysis. A more proper parallel in
Symbolics Common Lisp is our violation of CLtL when we cons &REST
arguments on the stack for efficiency. Symbolics should take whatever
performance hit is necessary to correct this, and work to devlop tools
which will make it easy to isolate cases where that performance hit is
important.
I'm also hopeful that stock hardware will, in the not so distant future,
have better instructions for LISP to use. I think there is a trend in
that direction, but I'm biased.
I'll also point out that many of my arguments affected ALL
implementations, not just "Lisp Machines". For instance, REMF removing
pointers to less volatile objects will benefit GC in any implementation,
particularly those with garbage collectors which concentrate their
efforts on recently created objects. I suspect that most CL
implementations will have such a GC in the near future.
The use of declarations naturally will tend to make code less portable,
so I think your use of THE FIXNUM above is contrived.
I've ported programs between CL implementations before, and I've never
come across problems which would have been avoided if
MAKE-EXPLICITLY-DEFINED were adopted. Instead, I find bunches and
bunches of problems where users write something which "is an error", but
is handled differently in two implementations. I therefore find it hard
to believe your position. Why aren't you trying to remove the phrase
"is an error" from the book if your goal is to have a portable language?
∂03-Nov-87 1909 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 87 19:09:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 NOV 87 19:08:02 PST
Date: Tue, 3 Nov 87 19:07 PST
From: Gregor.pa@Xerox.COM
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12345386056.BABYL@C.CS.CMU.EDU>
Message-ID: <871103190737.2.GREGOR@SPIFF.isl.parc.xerox.com>
Line-fold: no
On the subject of require and provide. I have a question which is "who
uses them?". I have seen lots of people say that they are so worthless
that they aren't good for much, I have seen lots of implementations of
"portable" compile and load drivers, I haven't seen much use of require
and provide.
Maybe we should either flush them or beef them up to the point that they
are really useful. Or perhaps they are useful and I just don't
understand how.
-------
∂03-Nov-87 1938 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 19:35:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Nov 87 22:36:23-EST
Date: Tue, 3 Nov 1987 22:36 EST
Message-ID: <FAHLMAN.12347808214.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
In-reply-to: Msg of 3 Nov 1987 22:07-EST from Gregor.pa at Xerox.COM
Right: nobody uses Provide and Require in portable code. Some people
figure out what they do in a particualr implementation and use them for
code on that system only. A total re-thinking is in order, probably as
a part of or after the cleanup of issues related to compilation
environment and how it affects the Lisp that called for the compilation.
-- Scott
∂04-Nov-87 0907 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Nov 87 09:07:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 NOV 87 09:01:36 PST
Date: 4 Nov 87 09:01 PST
From: Brotsky.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 3 Nov 87 14:06 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <871104-090136-1930@Xerox>
KMP writes:
The presence of an operator like GET-PROPERTIES in the
language acknowledges the fact that property list as we have
come to use it is not just an abstract table as some would
have it be, but in fact an ordered entry capable of doing a
restartable multiple lookup...
I agree completely.
... In my view, this invites (almost begs) the user to
exploit shadowing or prioritizing...
I agree completely.
... If (SETF GETF) is permitted to alter an existing
ordering, I believe that many programs which use
GET-PROPERTIES will be gratuitously broken.
Perhaps (even probably) true. But this is only remotely connected with
the two points KMP makes which I agree with. Once you get your hands on
a property list, you can certainly exploit your knowledge that it's an
ordered entry to use shadowing and prioritizing IF you know how that
list is going to be searched and updated by your search and update
functions. Now we all seem to agree that GETF searches property lists
front to back, so there's no problem with GETF per se. The problem is
in (SETF GETF) and REMF, about which CLtL simply does not say anything
like "(SETF GETF) and REMF are guaranteed to leave the order of the
pairs in a property list intact" and certainly nothing like "(SETF GETF)
and REMF are guaranteed to leave the particular conses used in a
property list intact (except possibly for removal in the case of REMF)."
I take the thrust of KMP's last remark to be that in fact there are LOTS
of programs out there that rely on one or both of these invariants which
will break if we allow implementations not to respect them. But then
let's be honest about why we would adopt MAKE-EXPLICITLY-DEFINED in this
case: we would adopt it so some existing code will be made portable ex
post facto. Exactly how much of this existing code will be made
portable will depend on exactly which invariants we adopt and how much
code assumes exactly those invariants. KMP seems to have a strong
feeling as to which invariants are being assumed; I would certainly
appreciate his (and anyone else's, for that matter) ballpark estimate of
how much code gets made portable by which invariants.
Frankly, I don't really have a problem with adopting a more precise
semantics for (SETF GETF) and REMF; after all, I think KMP's point about
encouraging shadowing etc. is well taken and the language should specify
*some* well-defined relationship between the plist updaters and
searchers which addresses ordering explicitly. So I'm willing to adopt
some version of MAKE-EXPLICITLY-DEFINED for (SETF GETF) and REMF, but I
sure would like to see more explicit discussion about balancing the
needs of making old code portable and not handcuffing implementors.
After all, if some existing program has a very exact---but restrictive
to implementors in general----semantics in mind for (SETF GETF) and
REMF, I don't see why that program couldn't implement it in very few
lines. I hate conditionalizing my code as much as the next person, and
I am constantly writing code that needs to run in more than one
implementation, but it's not clear to me that---especially in the case
of something as localized as (SETF GETF) and REMF---the particular
semantics of particular programs should be adopted by this community as
dictating what implementations must do.
dan
∂04-Nov-87 1125 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 11:25:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184902; Wed 4-Nov-87 14:17:54 EST
Date: Wed, 4 Nov 87 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871029151550.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871104191709.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 29 Oct 87 15:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Oct 87 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
I don't understand what you find insufficiently explicit about this now.
Do you mean that we should say
(defun (setf foo) ...) works like (defun foo ...)
(flet (((setf foo) ... works like (flet ((foo ...
(declare (inline (setf foo))) works like (declare (inline foo))
(symbol-function '(setf foo)) works like (symbol-function 'foo)
and so on for all the rest of them?
That seems pretty pointless to me. You must mean something more profound,
but I don't see what.
...
I don't think I meant anything drastically profound in any given case, but I
do think it's more important to do this enumeration than you're suggesting.
Many ``obvious'' things follow from the statements in your proposal, but some
of them may be surprising to some people, depending on how far their forward
chaining theorem prover runs when they read the descriptions you've provided.
I guess you're right. I don't think I'm going to find the time to elaborate
this proposal in the immediate future though.
And in a few cases, I bet we've not thought out all the consequences enough
to realize the subtle pitfalls that might follow...
I don't think so, but let's discuss the individual points you listed below.
* Some people will distrust their ability to extrapolate and be likely
to say to themselves: ``Surely they couldn't have meant that I should
write (SYMBOL-FUNCTION '(SETF FOO)).'' By stating this explicitly,
we'll confirm that this extrapolation is correct.
I can't imagine anyone seriously thinking this, when the proposal says:
The functions,
macros, and special forms defined in CLtL and listed in the References
section above need to be enhanced to accept such lists in addition to
symbols as function names, so that setf functions can be defined and
manipulated.
If this doesn't mean that SYMBOL-FUNCTION accepts such a list in addition
to accepting a symbol, then what does it mean?
Aside: in the next edit, the above sentence should read "The functions,
macros, special forms, and declarations ...."
* Some people may expect that
(DEFUN (SETF FOO) (VAL) ...)
sets up (DOCUMENTATION '(SETF FOO) 'FUNCTION) while others may expect
that it sets up (DOCUMENTATION 'FOO 'SETF). Some may expect that
(DOCUMENTATION 'FOO 'SETF) is oboleted, while others may assume that
you now have to know how the SETF thing was defined in order to get
its documentation. Others may expect (DOCUMENTATION 'FOO 'SETF) to
apply only to SETF macros and (DOCUMENTATION '(SETF FOO) 'FUNCTION)
to apply to SETF functions, independently of how they're defined.
You're right that the proposal needs to say that we are not changing what
CLtL says about (documentation foo 'setf), namely that it applies to defsetf
(and define-setf-method, that's an omission in CLtL).
* Some people may wonder whether (FLET ((FOO ...)) ...) will implicitly
make (SETF FOO) lexically funbound.
I can't imagine why anyone would think that. Common Lisp doesn't even
have a concept of lexically funbound names (although I think it perhaps ought
to).
By writing things out in English,
we have a place where we can be explicit remarks about this. They may
be redundant with logical consequences of things you've already written,
but I think some such redundancy is appropriate in a proposal of this
kind.
* By the way, some people, myself included, have functions which map
down existing linguistic constructs such as declarations and do things
like GET on them because they presuppose that the things they're
operating on will be symbols. Since GET works only on symbols, such
code will be broken by this so-called upward compatible change.
By that reasoning, no language extension of any sort is ever upward compatible,
because a program that purports to understand the entire language won't
know about it. So I think when we call a change upward-compatible, we must
not be referring to its effect on program-understanding programs.
A more
subtle consequence is something which takes a function name and does
MEMBER into a list of function names. That won't blow out but unless
:TEST #'EQUAL is added, it will no longer reliably find the function name.
By mentioning things like (PROCLAIM '(INLINE (SETF FOO))) you may trigger
a red flag in some people's brains that alerts them to a potential
impact of this change which you had not anticipated.
The proposal does say that the INLINE declaration works with (SETF FOO). I don't
see why the INLINE declaration is more likely to trigger a "red flag" than anything
else, though. You're right that some programs that assume all function names
are symbols will break if someone feeds them one of these new function names.
In the next version we should add a brief note about that to "conversion cost"
(not "adoption cost", because these programs are not required by CLtL, but are
something added on top of Common Lisp, even if they are written by implementors
and used as part of a Common Lisp compiler. At least, that's my understanding of
the difference between these two very similar sections of the CL-Cleanup form.)
* You need to specify things like how the implicit block in (SETF FOO)
generalizes. Does (RETURN-FROM (SETF FOO) ...) work, or does it just
create a (BLOCK FOO ...).
Good point, that should be added in the next version.
I could probably think of more of these. I think that by making a little paragraph
that claims to explain the extrapolation technique for each of these functions,
we will make it more likely that someone will notice other little nagging oversights
that need to be explicitly addressed. As long as you just say "and these will
be attended to in the obvious way" there is nothing to criticize/correct and yet
grave potential for loose ends to be left dangling.
I will send out a revised proposal with the above small corrections, but I don't
think it's desirable to write a whole paragraph about each of the 16 language
entities named in the References section. Note that the proposal says nothing
about "attended to in the obvious way".
∂04-Nov-87 1126 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 11:26:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184904; Wed 4-Nov-87 14:27:05 EST
Date: Wed, 4 Nov 87 14:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19871104192703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂04-Nov-87 1138 CL-Cleanup-mailer SETF-FUNCTION-VS-MACRO (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 11:38:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271978; Wed 4-Nov-87 14:17:28 EST
Date: Wed, 4 Nov 87 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871029151550.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871104191709.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 29 Oct 87 15:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Oct 87 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
I don't understand what you find insufficiently explicit about this now.
Do you mean that we should say
(defun (setf foo) ...) works like (defun foo ...)
(flet (((setf foo) ... works like (flet ((foo ...
(declare (inline (setf foo))) works like (declare (inline foo))
(symbol-function '(setf foo)) works like (symbol-function 'foo)
and so on for all the rest of them?
That seems pretty pointless to me. You must mean something more profound,
but I don't see what.
...
I don't think I meant anything drastically profound in any given case, but I
do think it's more important to do this enumeration than you're suggesting.
Many ``obvious'' things follow from the statements in your proposal, but some
of them may be surprising to some people, depending on how far their forward
chaining theorem prover runs when they read the descriptions you've provided.
I guess you're right. I don't think I'm going to find the time to elaborate
this proposal in the immediate future though.
And in a few cases, I bet we've not thought out all the consequences enough
to realize the subtle pitfalls that might follow...
I don't think so, but let's discuss the individual points you listed below.
* Some people will distrust their ability to extrapolate and be likely
to say to themselves: ``Surely they couldn't have meant that I should
write (SYMBOL-FUNCTION '(SETF FOO)).'' By stating this explicitly,
we'll confirm that this extrapolation is correct.
I can't imagine anyone seriously thinking this, when the proposal says:
The functions,
macros, and special forms defined in CLtL and listed in the References
section above need to be enhanced to accept such lists in addition to
symbols as function names, so that setf functions can be defined and
manipulated.
If this doesn't mean that SYMBOL-FUNCTION accepts such a list in addition
to accepting a symbol, then what does it mean?
Aside: in the next edit, the above sentence should read "The functions,
macros, special forms, and declarations ...."
* Some people may expect that
(DEFUN (SETF FOO) (VAL) ...)
sets up (DOCUMENTATION '(SETF FOO) 'FUNCTION) while others may expect
that it sets up (DOCUMENTATION 'FOO 'SETF). Some may expect that
(DOCUMENTATION 'FOO 'SETF) is oboleted, while others may assume that
you now have to know how the SETF thing was defined in order to get
its documentation. Others may expect (DOCUMENTATION 'FOO 'SETF) to
apply only to SETF macros and (DOCUMENTATION '(SETF FOO) 'FUNCTION)
to apply to SETF functions, independently of how they're defined.
You're right that the proposal needs to say that we are not changing what
CLtL says about (documentation foo 'setf), namely that it applies to defsetf
(and define-setf-method, that's an omission in CLtL).
* Some people may wonder whether (FLET ((FOO ...)) ...) will implicitly
make (SETF FOO) lexically funbound.
I can't imagine why anyone would think that. Common Lisp doesn't even
have a concept of lexically funbound names (although I think it perhaps ought
to).
By writing things out in English,
we have a place where we can be explicit remarks about this. They may
be redundant with logical consequences of things you've already written,
but I think some such redundancy is appropriate in a proposal of this
kind.
* By the way, some people, myself included, have functions which map
down existing linguistic constructs such as declarations and do things
like GET on them because they presuppose that the things they're
operating on will be symbols. Since GET works only on symbols, such
code will be broken by this so-called upward compatible change.
By that reasoning, no language extension of any sort is ever upward compatible,
because a program that purports to understand the entire language won't
know about it. So I think when we call a change upward-compatible, we must
not be referring to its effect on program-understanding programs.
A more
subtle consequence is something which takes a function name and does
MEMBER into a list of function names. That won't blow out but unless
:TEST #'EQUAL is added, it will no longer reliably find the function name.
By mentioning things like (PROCLAIM '(INLINE (SETF FOO))) you may trigger
a red flag in some people's brains that alerts them to a potential
impact of this change which you had not anticipated.
The proposal does say that the INLINE declaration works with (SETF FOO). I don't
see why the INLINE declaration is more likely to trigger a "red flag" than anything
else, though. You're right that some programs that assume all function names
are symbols will break if someone feeds them one of these new function names.
In the next version we should add a brief note about that to "conversion cost"
(not "adoption cost", because these programs are not required by CLtL, but are
something added on top of Common Lisp, even if they are written by implementors
and used as part of a Common Lisp compiler. At least, that's my understanding of
the difference between these two very similar sections of the CL-Cleanup form.)
* You need to specify things like how the implicit block in (SETF FOO)
generalizes. Does (RETURN-FROM (SETF FOO) ...) work, or does it just
create a (BLOCK FOO ...).
Good point, that should be added in the next version.
I could probably think of more of these. I think that by making a little paragraph
that claims to explain the extrapolation technique for each of these functions,
we will make it more likely that someone will notice other little nagging oversights
that need to be explicitly addressed. As long as you just say "and these will
be attended to in the obvious way" there is nothing to criticize/correct and yet
grave potential for loose ends to be left dangling.
I will send out a revised proposal with the above small corrections, but I don't
think it's desirable to write a whole paragraph about each of the 16 language
entities named in the References section. Note that the proposal says nothing
about "attended to in the obvious way".
∂04-Nov-87 1148 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 11:48:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272027; Wed 4-Nov-87 14:49:30 EST
Date: Wed, 4 Nov 87 14:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871026-163446-2308@Xerox>
Message-ID: <19871104194928.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments on excerpts from version 3 of the proposal:
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa.
Coercion of a vector to an array doesn't make any sense, since a vector
is already an array. I think what you must really mean here is to
generalize the first bullet on CLtL p.51 to say "any sequence or array
type can be converted to any other sequence or array type..." and to
add that this includes coercions that change the rank of an array and
coercions between lists and arrays of rank other than 1. We have to
explain how array rank changes, and array dimension changes, renumber
the elements; basically row-major order, but a somewhat more verbose
explanation is probably appropriate.
In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
I don't see anything about number of elements on p.51 of CLtL. I only
see a comment about type of elements. Is this a separate cleanup proposal
to define whether (coerce "foo" '(vector * 2)) returns #(#\f #\o) or
signals an error? What about (coerce "foo" '(vector * 4))? I think that
should be dealt with in a separate proposal. If you want current practice
input, both of these signal an error in Symbolics Common Lisp.
If it's clarified as I suggest, I would agree with this part.
2) Modify the definition of MAKE-SEQUENCE to accept array descriptions
as well as vector descriptions.
I disagree with this, but also I'm not sure what it says. If it means
that MAKE-SEQUENCE should be able to return an array of rank other than 1,
I disagree, because I don't think we are proposing to extend the type
named SEQUENCE to include such arrays. On the other hand, if it means
that (make-sequence '(array double-float 1) 5) should be valid, as far
as I can tell it is already valid. If it's based on someone's idea
of the internal implementation of SUBSTITUTE, REVERSE, and MAP, doing
(MAKE-SEQUENCE (TYPE-OF argument) (LENGTH argument)), I think that's a
silly reason to change the language.
3) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow
arrays.
Again, say "of rank other than 1" since they already allow rank-1 arrays.
These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected
functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY,
NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE,
NREVERSE, SORT.
I agree with this.
Extend the definitions of sequence functions whose result should be the
same shape as but not necessarily EQ to some argument. These functions
should deal with array arguments by returning an array of the same
shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.
I agree with this.
Expressly forbid arrays as arguments to sequence functions that modify
the number of elements in the array because the shape would be
undefined. These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE,
REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Does the novel phrase "expressly forbid" mean that CLtL leaves this open to
extension ("is an error"), or that CLtL requires this to signal an error,
or does it mean something else? I guess I prefer "is an error".
Conclusion: I support sending this to X3J13 but would like to see
the language of the proposal made crisper as suggested above.
∂04-Nov-87 1449 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 14:46:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272239; Wed 4-Nov-87 17:47:31 EST
Date: Wed, 4 Nov 87 17:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871104-090136-1930@Xerox>,
<19871103210016.9.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>,
<871103140614.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<871103-085958-2800@Xerox>,
<19871103035217.7.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>,
<871102-182243-2120@Xerox>,
<19871103004347.9.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>,
<871031-165117-6815@Xerox>,
<FAHLMAN.12346756507.BABYL@C.CS.CMU.EDU>,
<871030-130821-5980@Xerox>,
<871030-114930-5868@Xerox>,
The message of 30 Oct 87 14:49 EST from Masinter.pa@Xerox.COM,
<871030-115402-5874@Xerox>,
The message of 30 Oct 87 14:53 EST from Masinter.pa@Xerox.COM,
<871030123158.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871104224738.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm with DLA on this one. I support the MAKE-EXPLICITLY-VAGUE proposal.
A few of the details of that proposal may need refinement.
I think it would be contrary to the original intent of Common Lisp to
require all implementations to work exactly the same way on these
side-effects. Perhaps that original intent is wrong and should be
changed, but the side-effects of destructive list operations don't
seem to me to be the place in need of changing first, in that case.
I'm not sure if the Cleanup committee is the right one to be redefining
the goals of Common Lisp to raise the priority of painless portability
of programs that depend on currently unspecified behavior, perhaps
that should be some other committee or X3J13 as a whole.
∂04-Nov-87 2045 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Nov 87 20:45:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 272393; Wed 4-Nov-87 21:17:56 EST
Date: Wed, 4 Nov 87 21:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
To: Masinter.pa@Xerox.COM, Fahlman@c.cs.cmu.edu
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871023-152308-1515@Xerox>
Message-ID: <19871105021803.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Oct 87 15:22 PDT
From: Masinter.pa@Xerox.COM
I think I tend to agree with Scott that I'd
rather see a little more shuffling in GETF and LDB and less in SETF of
symbols.
It seems to me that the issue is whether we believe what CLtL says on
p.105 or what it says on p.106. They contradict each other, because if
you combine that setf method for LDB with that setf method for symbols,
you get a Common Lisp that doesn't work.
I claim that user programs are much more likely to have copied the setf
method for LDB given on p.106 than the setf method for symbols
schematized on p.105, and therefore if we disbelieve p.106 the change is
more incompatible. I withdraw the mistaken claim I made originally
that it is impossible to make a valid Common Lisp while believing
p.105.
Hopefully, SETF-FUNCTION-VS-MACRO would reduce the amount of
hair that was involved for users of setf, anyway.
In general yes, but not in the cases at issue here; SETF of GETF
and of LDB cannot be implemented as setf functions, for reasons that
are obvious as soon as you think about it.
I might have further comments later, but I thought I'd fire this one
off now since I'm on my way home.
∂08-Nov-87 1119 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 11:19:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274769; Sun 8-Nov-87 14:18:53 EST
Date: Sun, 8 Nov 87 14:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871026-165748-2355@Xerox>
Message-ID: <19871108191910.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor version 3 of SHADOW-ALREADY-PRESENT and the proposal
SHADOW-ALREADY-PRESENT:WORKS. The epigram was just there to
test whether anyone was reading all the way through, and of
course should not be included in the published version.
∂08-Nov-87 1133 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 11:33:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274773; Sun 8-Nov-87 14:33:26 EST
Date: Sun, 8 Nov 87 14:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TRACE-FUNCTION-ONLY (Version 4)
To: kempf%hplabsz@hplabs.HP.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <3685.562609071@hplabsz>
Message-ID: <19871108193338.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor version 4 of this discussion, and I favor the proposal named
TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION (it's really supposed to be
named TRACE-FUNCTION-ONLY:FUNCTION-SPECIFICATION, isn't it?), provided
the Adoption Cost section is edited to point out that this is an
incompatible change for several implementations that already extend
Common Lisp by defining the meaning of a non-symbol as a subform of
TRACE. In particular, at least Symbolics Common Lisp, Xerox Common
Lisp, and CMU Common Lisp define a list as a subform of TRACE to
be something other than a function-spec, and probably a lot of other
implementations do something like this.
I favor the change even though it's incompatible, because TRACE is part
of the environment rather than part of the programming language, meaning
that compatibility is less of an issue, and because all of the existing
extended syntaxes of TRACE that I am aware of are horrible.
∂08-Nov-87 1154 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 11:54:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274779; Sun 8-Nov-87 14:54:19 EST
Date: Sun, 8 Nov 87 14:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
To: cl-cleanup@SAIL.STANFORD.EDU, Hornig@SCRC.Symbolics.COM
In-Reply-To: <871027-145108-1674@Xerox>
Message-ID: <19871108195430.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't think this issue is nearly ready for release, for two reasons:
(1) The discussion appears to have been thoroughly garbled during
editing. KMP pointed out some problems in his message of 28 October,
but I noticed several more while reading it just now. I could provide
line-by-line commentary if requested, but I'm not sure that's the best
use of limited time right now.
(2) Of the several alternative proposals for this issue, the only one
that seemed appropriate to me has been removed. After re-reading the
12 messages on the topic that I thought were worth saving, I get the
feeling that the issues have not really been clarified and that the
discussion is largely dealing with strawmen. It seems like the
cleanup committee is heading towards making a serious mistake here.
I could spend several hours now rearguing the same arguments I made last
spring, hopefully putting more care and clarity into them so that more
people would be convinced. It's a subtle issue that's hard to think
about and I'm sure my past comments on it have not been as
understandable as they ought to be. However, again this issue seems
like a waste of time right now. I'd rather concentrate on cleanup
issues that are closer to agreement.
∂08-Nov-87 1207 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 12:06:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274781; Sun 8-Nov-87 15:06:19 EST
Date: Sun, 8 Nov 87 15:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 2)
To: Masinter.pa@Xerox.COM
cc: peck@Sun.COM, CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871023-170117-1668@Xerox>
Message-ID: <19871108200633.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Oct 87 17:01 PDT
From: Masinter.pa@Xerox.COM
Version 3 will change
>> The phase "subforms of the reference" which appears several times in
>> CLtL should be made more specific to be "subforms of the
>> [generalized-variable manipulating macro] arguments".
to
>> The phase "subforms of the reference" which appears several times in
>> CLtL should be made more specific to be "arguments of the
>> [generalized-variable manipulating] macro".
We like to get it right in the proposals.
Still not right, I think. The term "arguments" is not in the index of
CLtL, but my reading of pp.57-9 is that the term "argument" refers to the
-result- of evaluating a subform of a function call, and the phrase
"arguments of a macro" is an oxymoron. CLtL 57 defines "macro call,"
so I think the phrase you are looking for above is:
"subforms of the macro call" (on p.99, context implies that
generalized-variable manipulating macros are referred to, in
some other places it might be necessary to say so explicitly.
Really we should provide a complete list of them.)
I don't see any definition of the word "subform" in CLtL either, although
it's used here and there. It means a form (that is, something whose
syntactic use is such that it will be evaluated) that is nested inside
another form. It does not mean any object nested inside a form regardless
of syntactic context. The distinction is only a distinction because of
special forms and macros, of course.
∂08-Nov-87 1220 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 12:19:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274789; Sun 8-Nov-87 15:19:44 EST
Date: Sun, 8 Nov 87 15:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PUSH-EVALUATION-ORDER (Version 2)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
In-Reply-To: <871023-103240-6617@Xerox>
Message-ID: <19871108202000.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is fine with me except for a couple of minor corrections noted
below.
Date: 23 Oct 87 10:32 PDT
From: Masinter.pa@Xerox.COM
I removed all but the :ITEM-FIRST
proposal, extended it to include INCF, DECF, PUSHNEW, and macros which
are created with DEFINE-MODIFY-MACRO
You forgot to add these to the References field, although they are
mentioned in the text in a couple of places. It would probably be
better to list everything that's going to be affected in the References
field, so no one gets confused.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
Explicitly state that for the macros that manipulate generalized
variables (PUSH, PUSHNEW, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF and
those defined with DEFINE-MODIFY-MACRO) the subforms of the macro
"of the macro call", to be strictly accurate.
(including but not limited to those of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program.
Good.
For example, PUSH is expected to behave as if described as:
(PUSH Item Place) is generally equivalent to (SETF Place (CONS Item
Place))
except that the subforms of Place are evaluated only once, and Item
is evaluated before Place."
I wonder why "roughly" changed to "generally".
The phase "subforms of the reference" which appears several times in
CLtL should be made more specific to be "subforms of the
[generalized-variable manipulating macro] arguments".
"subforms of the macro call". Also "subforms" doesn't seem to be
officially defined anywhere, we need to be clear on this (see the
message I sent earlier today, same subject).
Cost of non-adoption:
Obvious programs may be non-portable, although it should be rare that
order of evaluation will effect actual operation.
"affect", unless you're making a very subtle joke here.
Discussion:
David Moon (Symbolics) argues that the unstated intention of page 99
is the definition of the language, while admitting that:
"The quoted paragraphs could be taken to restrict order of evaluation
only
of the subforms of (CAR (ref2)), not all of the subforms of the PUSH
form."
I think you ought to put back the other part of my comment, since in
removing it my argument is eviscerated. The paragraph on p.99 two
paragraphs after the one referenced makes it clear, at least to me,
that "subforms of generalized-variable references" was a typo, since
it discusses order of things that aren't such subforms.
I'll send out a proposed revision of the discussion in a second message,
in just a moment.
∂08-Nov-87 1242 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 12:41:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274799; Sun 8-Nov-87 15:41:36 EST
Date: Sun, 8 Nov 87 15:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PUSH-EVALUATION-ORDER (Version 3)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
In-Reply-To: <871023-103240-6617@Xerox>
Message-ID: <19871108204151.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I propose this revision of the discussion of this issue, with
minor corrections according to comments sent in my previous two
messages this afternoon commenting on version 2 of the proposal.
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Category: CLARIFICATION
Edit History: Jeff Peck, 15-Oct-1987, version 1.
Larry Masinter, 23-Oct-87, version 2.
David Moon, 8-Nov-87, version 3.
Problem Description:
In the form: (PUSH (ref1) (CAR (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Other macros that manipulate generalized variables include ... PUSH....
Macros that manipulate generalized variables must guarantee the
`obvious' semantics: subforms of generalized-variable references
are evaluated ... in exactly the same order as they appear in
the *source* program."
That is, the sub-forms of Place should be evaluated once, left to right.
"The expansion of these macros must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the subforms of the
reference."
This paragraph and a discussion of SETF on the previous pages may also
be interpreted as requiring that *all* subforms of such macro calls
should be evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."
That is, the effect of the form (PUSH Item Place) is to evaluate
(SETF Place (CONS Item Place)) but with subforms of Place only evaluated
once.
Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form. Should the PUSH form have primacy over
the obvious SETF form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or
only those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized
variables, e.g., PUSHNEW, INCF, DECF, and those defined with
DEFINE-MODIFY-MACRO.
Test Case:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
If the subforms evaluate in left-to-right order, this will print 12
rather than 21.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
Explicitly state that for the macros that manipulate generalized
variables (PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF,
PSETF, SETF, POP, and those defined with DEFINE-MODIFY-MACRO) the
subforms of the macro call (including but not limited to subforms of the
generalized variable reference) are evaluated exactly as many times as
they appear in the source program, and in exactly the same order as they
appear in the source program. Explicitly state that for the macros
CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
where CLtL specifies to the contrary.
In this context, "subform" means a form (that is, something whose
syntactic use is such that it will be evaluated) that is nested inside
another form. It does not mean any object nested inside a form
regardless of syntactic context.
For example, PUSH is expected to behave as if described as:
(PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place)) except that the subforms of Place
are evaluated only once, and Item is evaluated before Place."
The phase "subforms of the reference" which appears several times in
CLtL should be made more specific to be "subforms of the macro call,"
referring to the entire form that calls the generalized-variable
manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended
definition of "obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In
the form (PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place
then Item. Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Adoption Cost:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost of non-adoption:
Obvious programs may be non-portable, although it should be rare that
order of evaluation will affect actual operation.
Benefits:
The implementation and semantics of PUSH become obvious to all.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this
clarification ensures consistency across the language.
Discussion:
David Moon (Symbolics) argues that the unstated intention of page 99
is the definition of the language, while admitting that:
"The quoted paragraphs could be taken to restrict order of evaluation
only of the subforms of (CAR (ref2)), not all of the subforms of the
PUSH form."
However, the second to last paragraph on page 99
As an example of these semantic rules, in the generalized-variable
reference (setf reference value), the value form must be evaluated
after all the subforms of the reference because the value form
appears to the right of them.
makes it clear, if it is still talking about the same semantic rules,
that in this context the phrase "generalized-variable reference" was
meant to refer to the entire macro call, not just the Place, and that
order of evaluation rules are not limited to subforms of Places. We
suggest that the next specification of Common Lisp should adopt more
consistent terminology.
No performance impact is expected; while some macro expansions may
appear to be more verbose, most compilers deal reasonably with the
required order of evaluation.
∂08-Nov-87 1307 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 13:06:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274804; Sun 8-Nov-87 16:06:42 EST
Date: Sun, 8 Nov 87 16:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871023-172918-1711@Xerox>
Message-ID: <19871108210657.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Oct 87 17:29 PDT
From: Masinter.pa@Xerox.COM
I attempted to make the change from "keyword" to Named-argument in this
version.
This issue was conditionally passed at the last X3J13 pending only the
terminology change.
Neither version 6 nor version 7 uses the terminology that CLtL uses.
Since I was the one who prompted attempts to change the terminology, and
I've now repudiated that idea (it seems to create more confusion than
it solves), I offer this revision, to use precisely the terminology
that CLtL now uses in the referenced pages. I also fixed some typos.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
23-Oct-87, Version 7 by Masinter
8-Nov-87, Version 8 by Moon
Problem Description:
CLtL says that only keyword symbols can be used as keyword-names in
&key parameter specifiers (page 60, "each -keyword- must be a
keyword symbol, such as :start.")
As Common Lisp is currently defined, if someone wants to define a
function that accepts keyword (rather than positional) arguments whose
keyword-names are symbols in packages other than the KEYWORD package,
they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the keyword-names of keyword
parameters; allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword symbol with the same print name as the variable is created and
is used as the keyword-name when matching arguments to parameter
specifiers. A keyword-name that is not a keyword symbol can be
specified with the ((-keyword- -var-)) syntax of parameter specifier.
The -keyword- can be any symbol, not just a keyword.
A future specification of Common Lisp could be written with revised
terminology that did not use the term "keyword" to refer to three
different things: symbols in the KEYWORD package, symbols beginning
with & that have special meaning in lambda-lists, and keyword-names
used to match function arguments to keyword parameter specifiers.
However, this proposal does not propose to change any terminology.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
keyword-names to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be in the KEYWORD package.
The desire for keyword parameters whose keyword-names are not in the
KEYWORD package arises when the set of keyword-names accepted by a
function is the union of the sets of keyword-names accepted by several
other functions, rather than being enumerated in a single place. In
this case, it becomes desirable to use packages to prevent accidental
name clashes among keyword-names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept arguments and pass
them on to one or more applicable methods, with each method defining its
own set of keyword-names that it is interested in. If this proposal is
not adopted, either the keyword-names will be required to be keywords,
which will require the methods to have non-modular knowledge of each
other in order to avoid name clashes, or the methods will have to be
defined with an ad hoc mechanism that duplicates the essential
functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary arguments from the
caller and passes those arguments along to an internal routine with
additional arguments of its own, and suppose that keyword parameters
are used to receive these arguments.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between "keyword", indicating a symbol
in the KEYWORD package, and "keyword name", indicating a syntactic part
of a keyword parameter specifier. It is likely that this is best served
by changing those instances of "keyword" to "named argument" when the
specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument name must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but may be mistaken.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂08-Nov-87 1334 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 6)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 13:34:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274813; Sun 8-Nov-87 16:33:50 EST
Date: Sun, 8 Nov 87 16:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 6)
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: willc%tekchips.tek.com@RELAY.CS.NET
In-Reply-To: <871023-115213-1106@Xerox>
Message-ID: <19871108213400.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
On the whole I favor this proposal, provided the corrections noted
in Fahlman's message of 25 October are made.
However I continue to dislike the coupling of the proposal to remove the
implicit coercion from FUNCALL, to the proposal to tighten up the
definition of the FUNCTION type. In my opinion this coupling is
logically unnecessary and has been done only for parliamentary reasons,
to prevent people from voting against removing the implicit coercion.
This coupling of two proposals prevents us from getting an unbiased poll
of X3J13's opinion on the tradeoff between the incompatible change and
the language simplification associated with removing the coercion.
∂08-Nov-87 1351 CL-Cleanup-mailer Issue: PATHNAME-STREAM (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Nov 87 13:50:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 274820; 8 Nov 87 16:50:42 EST
Date: Sun, 8 Nov 87 16:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871023-095238-6542@Xerox>
Message-ID: <19871108215056.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Oct 87 09:52 PDT
From: Masinter.pa@Xerox.COM
In this version, I explicitly disallow synonym streams (and two-way,
echo, string, broadcast streams), and explicitly allow streams created
with open and with-open-file.
I believe synonym streams should pass the PATHNAME operation on to their
target, and therefore a synonym stream should be acceptable for coercion
to a pathname if its current target is acceptable. This seems to me to
be more consistent with the intent of p.329, although since the term
"operations" [on a stream] does not seem to be defined anywhere, it's
hard to be sure. Also it seems useless to have a restriction against
synonym streams here.
I enhanced the discussion section, and
added a reference to p. 417 "the name returned represents the name used
to open the file, which may not be the actual name of the file".
I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?
The second paragraph under namestring on p.417 seems very explicit that
the pathname that was supplied to OPEN must be remembered. Of course
file systems are by nature so implementation-dependent that it would be
difficult for someone to construct an unequivocal test case that would
catch XCL out. The relation between a pathname and its truename cannot
really be defined in an implementation-independent way, I think.
Version 5 of PATHNAME-STREAM:FILES-ONLY is fine with me otherwise.
Typos:
NAMESTRING etc. (p. 417) should be added to the references.
The edit history has two entries for version 4.
Right at the end, "currently no way portable" has two words
interchanged.
∂09-Nov-87 0900 CL-Cleanup-mailer Issue Status
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 08:59:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275227; Mon 9-Nov-87 12:00:47 EST
Date: Mon, 9 Nov 87 12:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue Status
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871024-175306-2269@Xerox>
Message-ID: <19871109170056.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 24 Oct 87 17:52 PDT
From: Masinter.pa@Xerox.COM
This is my status file as of today. Please give your attention to the
???? issues; if you want to send me one general message covering your
opinion or non-opinion on various messages, I will try to sort it out.
This is a rather overwhelmingly long list but I'll see what I can do.
I don't recall seeing answers to this from anyone else; were we supposed
to send them just to you Larry rather than to the whole mailing list?
I've omitted issues where I don't have an opinion, in some cases because
I don't remember what the issue is. I also omitted issues that I sent
separate mail about very recently.
Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
% need volunteer to write up
???? A question: Please reply.
~ Tabled until resubmitted, i.e., no immediate action proposed.
* Proposal format (Version 12, 23-Oct-87)
???? Ready for release?
This is surely ready for release.
* AREF-1D (Version 6/6 JUL 87)
???? Ready for release with endorsement?
Yes.
* DECLARE-MACROS (version 1, 22-oct-87)
(Allowing macros to expand into declarations is not worth
the ambiguity & implementation cost.)
???? Ready for release?
Probably, since I don't think there was any controversy, but I'm not
sure since I haven't read the proposal yet.
{ DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Await object proposal.
{ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Await object proposal.
The CLOS subcommittee doesn't plan to propose any changes to DEFSTRUCT,
other than noting that once CLOS is adopted someone could propose to
eliminate DEFSTRUCT. So the status of the above two should probably
change from { to % (need volunteer).
* DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
(Documentation string is not evaluated.)
Submitted, no replies
???? Ready for release with endorsement?
Yes. (I haven't reviewed the actual wording of the proposal,
but I presume what it says is obvious from the summary here.)
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?
I expect so, but don't remember this one and don't seem to have a copy
of it.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
???? Ready for release?
I expect this is ready to release, although I don't have a copy of
the latest version.
& LOAD-TIME-EVAL (Version 2, 17-JUL-87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
No discussion after Version 2.
???? ready for release?
What does & mean? It's not in the table of annotations at the front
of the file. Version 2 of this looks ready for release.
* OPEN-KEYWORDS-EXISTS (Version 1, 17-Jul-87)
No discussion.
???? Ready for release ?
I don't know what this one is.
SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 9-Mar-87)
(What package are *features* in?)
Mild support for :KEYWORD
Register *features*?
???? Report out with only :KEYWORD proposal?
Report out with only :KEYWORD proposal.
∂09-Nov-87 1032 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 10:32:50 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275344; Mon 9-Nov-87 13:33:27 EST
Date: Mon, 9 Nov 87 13:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19871108191910.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109133311.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
SHADOW-ALREADY-PRESENT:WORKS looks fine to me.
∂09-Nov-87 1045 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 10:45:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275360; Mon 9-Nov-87 13:43:00 EST
Date: Mon, 9 Nov 87 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871023-163235-1628@Xerox>
Message-ID: <19871109184315.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This document looks ready for release.
I favor PATHNAME-SYMBOL:NO.
∂09-Nov-87 1055 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 10:54:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275387; Mon 9-Nov-87 13:53:29 EST
Date: Mon, 9 Nov 87 13:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871022104113.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871109185339.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks ready to release, with two minor wording corrections:
For example,
certain efficiency problems in the Symbolics compiler have been traced
to this feature.
Most of the efficiency problems are not due to this feature, so perhaps
this sentence should simply be deleted. The proposal could use
shortening anyway.
Make it illegal for a macro call to expand into a DECLARE form and be
recognized as such.
Strictly speaking there is no such thing as a DECLARE form, since a list
whose car is the symbol DECLARE is an error to evaluate. CLtL p.153
uses the term "declaration" for this, although I admit it also says
"declare form" in one place. Anyway I'd feel more comfortable if we
said "declaration" here.
I favor DECLARE-MACROS:FLUSH.
∂09-Nov-87 1058 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 10:58:06 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275393; Mon 9-Nov-87 13:58:57 EST
Date: Mon, 9 Nov 87 13:58 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19871109185339.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109135845.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 9 Nov 87 13:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This looks ready to release, with two minor wording corrections:
...
Make it illegal for a macro call to expand into a DECLARE form and be
recognized as such.
Strictly speaking there is no such thing as a DECLARE form, since a list
whose car is the symbol DECLARE is an error to evaluate. CLtL p.153
uses the term "declaration" for this, although I admit it also says
"declare form" in one place. Anyway I'd feel more comfortable if we
said "declaration" here.
How about "declare expression"? I had deliberately avoided the term
"declaration" because I wasn't clear if a "proclaim form" was a
declaration. Perhaps we should explicitly acknowledge that we don't intend
to keep macros from expanding into declare forms to avoid later confusion
on the issue.
∂09-Nov-87 1109 CL-Cleanup-mailer OPEN-KEYWORDS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:09:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275409; Mon 9-Nov-87 14:10:22 EST
Date: Mon, 9 Nov 87 14:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870724132524.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871109191026.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Is this the one that's listed in the status report as:
* OPEN-KEYWORDS-EXISTS (Version 1, 17-Jul-87)
No discussion.
???? Ready for release ?
The date matches, although the issue name is different.
The category should clarify that it's an incompatible change. Other
than that, this looks ready for release. If it was a compatible change
I would favor it, but since it's incompatible I'd have to think for a
while before I have any opinion.
Date: Fri, 24 Jul 87 13:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Issue: OPEN-KEYWORDS
References: Pages 420-422
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 07/17/87
Problem Description:
The :if-exists and :if-does-not-exist arguments interact, but keyword
arguments should generally be orthogonal.
I expect we can find plenty of other places in Common Lisp where keyword
arguments are not truly orthogonal, so that's a fairly weak argument.
Proposal (OPEN-KEYWORDS:ORTHOGONAL):
Delete the following phrases from the first 2 paragraphs on page 422:
", or if the :if-exists argument is :overwrite or :append" and
", and the if-exists argument is anything but :overwrite or :append"
Test Case:
The following piece of code causes an error to be signaled:
(open "test" :direction :output :if-exists :overwrite)
if a file named "test" -doesn't- already exist.
With the change in this proposal, it wouldn't be an error.
Rationale:
As is clear from the test case example, a user might want to specify
that a certain action get taken in the case that a file already
exists, without affecting what happens in the case that it doesn't
exist. There is no good reason for the two cases to affect each
other.
Current Practice:
Adoption Cost:
Slight.
Benefits:
More sensible, easier to understand, more efficient to use and to
implement.
Conversion Cost:
Slight, automatable.
Esthetics:
Keyword arguments are supposed to be orthogonal, thus this deviation
is unaesthetic. It being so contrary to intuition makes it particularly
difficult for new LISP users to grasp.
Discussion:
∂09-Nov-87 1122 CL-Cleanup-mailer DECLARE-MACROS (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:22:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275425; Mon 9-Nov-87 14:22:05 EST
Date: Mon, 9 Nov 87 14:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871109135845.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871109192215.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 9 Nov 87 13:58 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 9 Nov 87 13:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This looks ready to release, with two minor wording corrections:
...
Make it illegal for a macro call to expand into a DECLARE form and be
recognized as such.
Strictly speaking there is no such thing as a DECLARE form, since a list
whose car is the symbol DECLARE is an error to evaluate. CLtL p.153
uses the term "declaration" for this, although I admit it also says
"declare form" in one place. Anyway I'd feel more comfortable if we
said "declaration" here.
How about "declare expression"? I had deliberately avoided the term
"declaration" because I wasn't clear if a "proclaim form" was a
declaration. Perhaps we should explicitly acknowledge that we don't intend
to keep macros from expanding into declare forms to avoid later confusion
on the issue.
I don't understand why anyone would think a proclaim form was a declaration.
I can see how they might think the object passed as an argument to PROCLAIM
should be called a declaration. "Declare expression" would be okay, although
I don't see why we can't use the terminology CLtL uses instead of making up
new terminology.
Your last sentence must be a typo, the whole point is to keep macros
from expanding into declare forms. Maybe "declare" should be "proclaim"?
Explicitly saying that sounds good (it already does, doesn't it?).
∂09-Nov-87 1153 CL-Cleanup-mailer Re: OPEN-KEYWORDS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:53:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 11:40:22 PST
Date: 9 Nov 87 11:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: OPEN-KEYWORDS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 9 Nov 87 14:10 EST
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871109-114022-3556@Xerox>
(Replying in roughly reverse order to various questions; I was out for
most of last week)
Yes, the issue was misnamed in the status report. Sorry.
I would prefer holding this issue until we get more responses. I believe
incompatible changes of well-specified behavior require strong
justification.
The only argument given here is an aesthetic one ("there's no good
reason" for it to work the way it says it works.)
I'm inclined to reject this, or at least send it back for further
justification.
∂09-Nov-87 1313 CL-Cleanup-mailer Re: Issue: PATHNAME-STREAM (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 13:13:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 13:13:11 PST
Date: 9 Nov 87 13:12 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 5)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sun, 8 Nov 87 16:50 EST
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871109-131311-3795@Xerox>
Some arguments against requiring synonym streams to delegate pathname
follow. None of these individually are compelling; I'd like to hear from
some of the rest of you on this issue.
- - - - - -
a) If the pathname of a stream has any requirement attached to it at
all, it would seem to be the requirement that, in the absence of any
external manipulation of the data or file system, one should be able to
use the pathname retrieve the same data. While "file" streams have some
implicit requirement here, synonym streams do not -- not any more than
concatenated streams, broadcast streams, or the like.
b) I can easily imagine extending pathnames to include non-file
streams, e.g.,
(open (make-pathname :host :broadcast :name (list stream-1 stream-2))
:direction :output)
== (make-broadcast-stream stream-1 stream-2)
(open (make-pathname :host :synonym :name '*terminal-io*) :direction
:both)
== (make-synonym-stream '*terminal-io*)
(open (make-pathname :host :string :name x) :direction :input)
== (make-string-input-stream x)
In such a design, the pathname for synonym, broadcast, concatenated,
etc. streams would reflect their current state.
c) To put it in CLOS terms, I'd expect PATHNAME to not be implemented
only for file stream classes; requiring PATHNAME to work on synonym
streams only adds another (unnecessary) method to the implementation.
d) Current practice is mixed: at least two implementations (Coral,
Xerox) do not implement meaningful pathnames for synonym streams. (Coral
signals an error, Xerox returns a null pathname. VaxLisp and Symbolics
delegate.)
- - - - - - - - -
I'd like to have this issue address in more detail what the "pathname"
of a stream is and can be expected to do; I think that elucidating what
we expect out of a pathname will help decide cases like synonym streams.
∂09-Nov-87 1317 CL-Cleanup-mailer Re: OPEN-KEYWORDS
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 13:17:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 290096; Mon 9-Nov-87 15:41:25 EST
Date: Mon, 9 Nov 87 15:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871109-114022-3556@Xerox>
Message-ID: <19871109204112.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 Nov 87 11:38 PST
From: Masinter.pa@Xerox.COM
I would prefer holding this issue until we get more responses. I believe
incompatible changes of well-specified behavior require strong
justification.
That sounds reasonable to me.
∂09-Nov-87 1412 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 7)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:12:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 14:02:57 PST
Date: 9 Nov 87 14:02 PST
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: FUNCTION-TYPE (Version 7)
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871109-140257-4006@Xerox>
I incorporated Scott's comments.
I wanted, but didn't know how, to include David's objection to the
coupling of the two proposals. I thought them necessary to couple
because redefining the function type without redefining FUNCALL would
require at least a rewriting of all of the descriptions of FUNCALL,
APPLY, the definition of "a function" and several other points in CLtL.
In preparing Version 6, I had overlooked a note that we had decided (at
one point) to remove section 6 on COMPILE and delegate it to a remark in
the discussion section. I did this and renumbered the subsequent
sections.
!
Issue: FUNCTION-TYPE
References: functions (p. 32), types (p. 33), FUNCTIONP (p. 76),
SYMBOL-FUNCTION (p. 90), APPLY (p. 107), COERCE (pp.
51-52)
... :TEST :KEY arguments (61 occurrances).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Version 6 by Masinter 23-Oct-87, only
STRICT-REDEFINITION
Version 7 by Masinter 9-Nov-87, minor cleanup
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs the
status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
In addition, the practice that APPLY, FUNCALL and the numerous functions
that take functional arguments (such as MAPC, MAPCAR, FIND-IF) can
potentially do the equivalent of SYMBOL-FUNCTION to go from a symbol to
its functional-value is a serious impediment to program analysis which
require the ability to determine by examining a program which functional
definitions might be accessed from it. For example, "selective linking"
(which would allow a delivery system to include only those parts of the
Common Lisp library actually accessed) is seriously hampered by the
numerous implicit coercions of symbols to functions.
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations
are free to define subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by all functions in
Common Lisp that take a functional argument suitable for FUNCALL or
APPLY. It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so "is an
error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears. Specifically,
it is an error to use the FUNCTION special form on a symbol that denotes
a macro or special form. (Some implementations may choose not to signal
this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the object and fail
only when the supposed function is called.
6. Extend the definition of COERCE to allow coercion of objects to type
FUNCTION. That is, "Some symbols and lists may be converted to
functions." (COERCE SYMBOL 'FUNCTION) performs SYMBOL-FUNCTION (getting
the top level function definition, the current lexical context is not
relevant), while (COERCE LIST 'FUNCTION) is equivalent to (EVAL
`(FUNCTION ,LIST)), i.e., it creates a function from a LAMBDA expression
by interpreting it as a list in the top level lexical environment.
7. Modify the description of the macro expansion process to say that
the value of *MACROEXPAND-HOOK* is coerced to a function before being
called as the expansion interface hook by MACROEXPAND-1.
Rationale:
This proposal provides a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
It also enhances the semantics of Common Lisp functional arguments to be
more consistent with other programming languages, and allows better
program analysis tools.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in this proposal,
however, although it corresponds more closely to Scheme and to the work
of the EuLisp community.
Adoption Cost:
Bringing type predicates (FUNCTIONP, etc.) into compliance should
require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified to deal
with functions that are not lists (but from which the list form can be
easily reconstructed if necessary).
Implementations may choose to convert FUNCALL and APPLY to the new
stricter form, but they are not required to do so. Since the use of a
symbol or lambda expression in place of a function "is an error", an
implementation may handle these cases as a local extension. Most
implementations that continue to provide the coercion will at least want
to install an optional warning in FUNCALL and APPLY to flag the use of
this non-portable feature in user code.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.
This proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee.
This proposal allows for better program analysis tools, enhances the
ability to do "selective linking" correctly. It makes it possible to
reduce the total size of a delivered application program. Only those
Common Lisp functions that are actually called need to be included;
implicit coercions tend to create loopholes through which *every*
function might be called.
Conversion cost:
This proposal may have a high conversion cost for some existing Common
Lisp programs. The changes to FUNCTIONP and the FUNCTION type
declaration is relatively easy to deal with. However, the strict
redefinition of FUNCALL, APPLY and functional arguments will require the
addition of an explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might
add run-time test in which the implementation still does the coercion
but that issues a warning message whenever the coercion is actually
needed. Alternatively, a "smart" code-walker or editor macro might find
all of the calls to FUNCALL, APPLY, and the 61 Common Lisp functions
that take :TEST or :KEY arguments and, if the argument is not already an
explicitly quoted FUNCTION form, wrap a COERCE around the body.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code depends on this behavior and would have to be modified if this
proposal is adopted; doing so will be difficult as these uses cannot
easily be detected from simple examination of the program. (Such code is
not currently portable because many existing Common Lisp implementations
already violate these assumptions. CLtL does not clearly state what
values SETF of SYMBOL-FUNCTION will accept and how that object may be
modified.)
Aesthetics:
Making the concept of a function well-defined is a simplification of the
language. This proposal is the cleanest of the alternatives; it defines
a FUNCTION data type and then requires every object used as a function
to be a FUNCTION. While many argue that removing automatic coercion
results in a simpler, cleaner, and more aesthetic language definition,
others have argued otherwise ("its all a matter of taste.")
Discussion:
This proposal has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be revised. (There was one suggestion to create a new type name
PROCEDURE and a new predicate PROCEDUREP and to leave FUNCTION and
FUNCTIONP alone, but it was not generally perceived as acceptable.) The
cleanup of the type hierarchy is important to the CLOS group.
There is much more disagreement about disallowing implicit coercions;
cleanup of implicit coercions are important for compatibility with other
Lisp standards work. One option discussed at length was similar to this
proposal, but allowed FUNCALL, APPLY and functions that take functional
arguments to accept any object that can be coerced to a function.
Some argue that it seems better to make the effort once (to remove the
implicit coercion) than to live forever with runtime coercion of
functional arguments and the resulting complexity.
Some have argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
If coercing was continued to be allowed, Common Lisp might need an
APPLICABLE-P predicate that is true of any object that is legal as a
functional argument to APPLY and FUNCALL, since FUNCTIONP would no
longer do this job.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
This proposal interacts with the proposal on compiler semantics: some
claim that strict-redefinition would allow further compiler
optimizations, since compiled FUNCALL is not required to go through
extensive inline checks.
Fahlman, Gabriel, Masinter and Matthews support
FUNCTION-TYPE:STRICT-REDEFINITION.
Pitman and Moon have expressed support for an alternative proposal which
would continue to allow coercion.
∂09-Nov-87 1412 CL-Cleanup-mailer Issue Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:12:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 14:03:32 PST
Date: 9 Nov 87 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue Status
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <19871109170056.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109-140332-4007@Xerox>
Thanks for your responses, David.
To reply to some of your remarks (more specific replies in other
messages):
>I don't recall seeing answers to this from anyone else; were we
supposed
>to send them just to you Larry rather than to the whole mailing list?
No one else has responded yet. (Hint hint).
I've changed the status of the DEFSTRUCT issues to be "Need volunteer to
sort out DEFSTRUCT issues post-CLOS." However, I think the CLOS
subcommittee should be encouraged to take these on, or that members of
the CLOS subcommittee should be encouraged to volunteer.
I mailed David another copy of FORMAT-COMMA-INTERVAL and
GET-SETF-METHOD-ENVIRONMENT and his replies to each.
The & on LOAD-TIME-EVAL should have been a *.
∂09-Nov-87 1557 CL-Cleanup-mailer Issue: TRACE-FUNCTION-ONLY (Version 5)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 15:57:17 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 9 Nov 87 15:38:33-PST
Received: from hplms2 by hplabs.HP.COM with SMTP ; Mon, 9 Nov 87 14:42:54 PST
Received: from hplabsz.hpl.hp.com by hplms2; Mon, 9 Nov 87 14:42:05 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Mon, 9 Nov 87 15:41:30 pst
To: masinter.pa@xerox.com
Cc: fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu,
kempf%hplabs@hplabs.HP.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: TRACE-FUNCTION-ONLY (Version 5)
X-Mailer: mh6.5
Date: Mon, 09 Nov 87 15:41:27 MST
Message-Id: <2214.563496087@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
(Font Note: UPPERCASE indicates bold, _this_ indicates italic)
--------------------------------------------------------------------------------
Issue: TRACE-CLOS
References: trace macro pp. 440-441
TRACE-ARGUMENT-FORMAT-OPTIONS
SETF-CLOS
Category: MODIFICATION
Edit history: Version 1, 21-Oct-87 Kempf
Version 2, 27-Oct-87 Kempf
Version 3, 28-Oct-87 Kempf
Version 4, 30-Oct-87 Kempf
Version 5, 9-Nov-87 Kempf
Problem description:
With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of particular
methods to be traced, rather than invocation of the entire generic
function. In addition, the current specification of TRACE does not
allow tracing of functions associated with SETF "methods", of macro
functions, nor of lexically defined functions or functions invoked via. their
function definition objects. While this proposal does not attempt
to address the latter two problems, since identification and/or tracing of these
is likely to be implementation dependent, it does leave
open the option for those implementations which can arrange it.
Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)
TRACE _{function-spec}*_ _[Macro]_
UNTRACE _{function-spec}*_ _[Macro]_
Invoking TRACE with a function specification causes the function specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. UNTRACE undoes any tracing. Calling TRACE without
any arguments prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.
A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent; however,
every implementation is required to support the following:
_symbol_-Invocations of the function or macrofunction named by
_symbol_ via. _symbol_ as a global name are traced.
(METHOD _generic-function-name-specification_
_{method-qualifiers}_*
_parameter-specializer-name-list_
)
If the method whose parameter specializer list, generic function
name specification, and method qualifiers are listed is tracable,
then invocations through the generic function name specification
will be traced.
(SETF _symbol_)-If the SETF function having the name specification
is tracable, it will be traced (see proposal SETF-CLOS for
more information on SETF name specifications).
Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.
Note that this proposal does not change the current Common Lisp
specification in the area of "open-coded" functions. In particular,
implementations need not arrange for tracing of "open-coded" functions,
including compiled self calls which do not go through the symbol-function
cell.
In the case of tracing macro expansions, the trace is of the call to
the macroexpansion funtion and not of executing the return code. Thus the
trace function need only print the calling form arguments and the
expanded form being returned. As with "open-coded" functions, implementations
which memoize the expansion code are under no obligation to report trace
information once the macro code has been memoized. The example section
provides an example of an interactive session tracing a macro expansion.
Example:
1 [LISP] > (defmacro test-trace (arg)
1 [LISP] > `(format T "~S~%" ,arg)
1 [LISP] > )
TEST-TRACE
2 [LISP] > (trace test-trace)
((MACROFUNCTION TEST-TRACE))
3 [LISP] > (test-trace 'foo)
Entering macrofunction TEST-TRACE with arguments:
(QUOTE FOO)
Leaving macrofunction TEST-TRACE with return values:
(FORMAT T "~S~%" (QUOTE FOO))
FOO
4 [LISP] >
Rationale:
Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods. Adoption of the
SETF-CLOS proposal will require means of tracing SETF functions. It is
also not possible to easily trace either SETF functions or macrofunctions
today.
This proposal does not address a number of additional features of TRACE
(adding breakpoints, system hooks for extensible debugging, etc.) which
may be included in other proposals. In addition, the proposal recongnizes
that TRACE is part of the enviroment, and that future versions of the
Common Lisp standard may want to specify it as such. Different criteria
may therefore apply for evaluating compliance, for example, stand alone
Common Lisp applications may not require environmental features like
TRACE which are primarily included for program development, and their
compliance to the standard should therefore not be judged on the basis
of whether or not they implement such environmental features.
Current practice:
There is currently no way which is standard across all implementations
to trace SETF functions, aside from macroexpanding a SETF form and using
the resulting name in a TRACE macro invocation. There is currently no way
which is standardized across all implementations to trace macroexpansion
functions when they are invoked through their global names, except through
complicated use of *MACROEXPAND-HOOK*.
Adoption Cost:
The proposed syntax is upwardly compatible with the current Common Lisp
syntax. It will require the addition of function specification parsing
and wrapper code to trace SETF function executions and macrofunction
executions. When the Common Lisp Object System is fully implemented,
wrapper code for tracing method execution will also be required.
The proposed syntax may be incompatible for several implementations
that already extend TRACE. In particular, at least Symbolics Common Lisp,
Xerox Common Lisp, and CMU Common Lisp define a list as a subform of
TRACE to be something other than a function-spec. However, compatibility
with existing implementations seems less of an issue here, since TRACE
is more a part of the environment.
Cost of non-adoption:
Implementations will provide this functionality in varying forms and
to varying degrees, thus making it harder for users to move between
one Common Lisp system and another. Some implementations may choose
not to provide the functionality, in which case users will suffer.
Benefits:
Allow programmers to obtain information on individual method
invocations, and on SETF function and macrofunction invocations
in a uniform way across all implementations.
Conversion Cost:
Minor re-write of the TRACE and UNTRACE macros, and supporting wrapper
generating functions. Some implementations which have made extensions
to TRACE will need to accommodate those extensions with the additional
syntax.
∂09-Nov-87 1558 CL-Cleanup-mailer DECLARE-MACROS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 15:58:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 15:57:05 PST
Date: 9 Nov 87 15:56 PST
From: Masinter.pa@Xerox.COM
Subject: DECLARE-MACROS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
LINE-FOLD: NO
Message-ID: <871109-155705-4230@Xerox>
I responded to Moon's suggestions for wording correction. I added an
explicit endorsement at the end.
In the interest of shortening the issue, I removed the argument about
destructive MACROEXPAND hooks, which, I think, is more controversial
than the support that it raises.
In order to avoid the controversy of what is a declaration, a declare
expression, a declare form, or a list whose car is DECLARE, I reworded
the proposal to be more explicit as to the intent, which is to negate
one specific paragraph in CLtL.
I run some risk of making things worse, at least in your eyes, so you
might want to cast yours on the PROPOSAL section and respond to me if
you are unhappy.
!
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
9-Nov-87, version 2 by Masinter
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macro expansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be exponential in the depth of nesting
unless a macro-expansion caching mechanism is added.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accommodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Under this proposal, it would not be "permissible for a macro call to
expand into a declaration and be recognized as such, provided that the
macro call appears where a declaration may legitimately appear." (CLtL
p. 154). Macros could not legitimately expand into declarations; the only
valid declarations would be a list whose CAR is the symbol DECLARE.
It would still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The advantages provided by the ability to have a macro form expand into
a declaration have been shown in practice to not be worth the price paid
elsewhere in the language.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Adoption Cost:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Conversion Cost:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY () `(DECLARE (SPEED 3) (SAFETY 0)))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL (DECLARE (SPEED 3) (SAFETY 0)) ,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
The cleanup committee unanimously endorsed this proposal.
∂09-Nov-87 1622 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 16:22:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 NOV 87 16:19:32 PST
Date: 9 Nov 87 16:19 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sun, 8 Nov 87 15:41 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
Message-ID: <871109-161932-4273@Xerox>
I'm a little uneasy about "Explicitly state that for the macros
CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
where CLtL specifies to the contrary."
I think that we also have to be careful about the following: suppose a
user defines
(defmacro wrong-order (x y) `(get ,y ,x))
If the user writes (push a (wrong-order (frob) (baz)))
are we willing to guarantee that "the subforms of the macro call
(including but not limited to subforms of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program. "?
Similarly if the user writes an "incorrect" setf-method, e.g.,
(defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z))
I wish this weren't so sticky. . . .
∂09-Nov-87 1711 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 17:11:07 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275890; Mon 9-Nov-87 20:02:03 EST
Date: Mon, 9 Nov 87 20:01 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM
In-Reply-To: <19871108195430.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109200150.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Although I agree with the proposal as stated, I feel very strongly
(partly out of empathy from previous situations where I've been
outnumbered on issues) that if he wants equal, unbiased space, he
should get it.
At the very least, we can remove a number of the proposal variants
that have no champions.
Perhaps Moon and I can draft a balanced proposal expressing both
points of view, but I doubt it can be done before this meeting.
And I agree with him that it's not a good idea to push on this
complicated issue at this late date if we aren't very close to
agreement on the presentation.
∂09-Nov-87 1720 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 17:20:31 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275899; Mon 9-Nov-87 20:21:19 EST
Date: Mon, 9 Nov 87 20:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19871108210657.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109202108.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY as expressed in
version 8.
I do have the following (non-preemptive) comments about things
that I'd like to see fixed, but I wouldn't hold up the proposal
over:
* In KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8), I would change:
((-keyword- -var-)) to ((-keyword- -var-) ...)
to make it clear that a default value is not being omitted.
Better safe than sorry.
* The spelling of "aesthetic" needs to be regularlized. Sometimes
you omit the leading "a", which I know is your preference, but
sometimes you let my spelling slip through. Genera's spell
program says it has a leading "a", by the way.
∂09-Nov-87 1738 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 17:38:35 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275913; Mon 9-Nov-87 20:39:22 EST
Date: Mon, 9 Nov 87 20:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 3)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <871023-163235-1628@Xerox>
Message-ID: <871109203911.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support PATHNAME-SYMBOL:NO (Version 3).
I did notice the following (non-preemptive) problem, which should
be fixed if convenient before the proposal goes out:
"... some users are used to type interactively ..."
should be
"... some users are used to typing interactively ..."
∂09-Nov-87 1903 CL-Cleanup-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 19:02:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 186648; Mon 9-Nov-87 22:03:28 EST
Date: Mon, 9 Nov 87 22:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871109202108.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871110030337.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 9 Nov 87 20:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY as expressed in
version 8.
I do have the following (non-preemptive) comments about things
that I'd like to see fixed, but I wouldn't hold up the proposal
over:
* In KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8), I would change:
((-keyword- -var-)) to ((-keyword- -var-) ...)
to make it clear that a default value is not being omitted.
Better safe than sorry.
Good point.
* The spelling of "aesthetic" needs to be regularlized. Sometimes
you omit the leading "a", which I know is your preference, but
sometimes you let my spelling slip through. Genera's spell
program says it has a leading "a", by the way.
I doubt that any occurrences of that word came from me. Was
"your preference" referring to me or to Larry?
∂09-Nov-87 1918 CL-Cleanup-mailer OPEN-KEYWORDS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 19:18:16 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275955; Mon 9-Nov-87 22:19:06 EST
Date: Mon, 9 Nov 87 22:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870724132524.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
References: <19871109191026.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871109221855.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I don't mind keyword orthogonality being used as a simplicity metric in
the "(a)esthetics" section. I do feel unsure about the way in which it
is presupposed that keyword orthogonality is an explicit and uniform
design goal. I think the wording of the proposal should be reworked so
as not to take such a goal for granted. (:TEST and :TEST-NOT are obvious
counter-examples to this design principle.)
In principle, for this particular case, I don't see anything wrong with
the orthogonal meanings for :if-exists and :if-does-not-exist that Skona
is trying to push. As Moon says, this might be fine if we were doing
things over, but given that it's an incompatible change, we should
proceed carefully.
In particular, the behavior is already fully well-defined if you just
specify all keyword arguments explicitly. We're only haggling over how
the defaults work. My personal opinion is that if you care enough to
worry, you should write the keyword explicitly in your code just so it's
clear to your reader that this is an issue you considered.
For example, a lone :IF-EXISTS :OVERWRITE seems to presuppose the
existence of a file to overwrite. Ditto for :APPEND. The absence of that
file -might- be due to this being the first time the program was run,
but more often it is not. As such, signalling an error is not without
some motivation of its own. If the programmer wants to assert that
he's overwriting a file that might not exist, I think
:IF-EXISTS :OVERWRITE :IF-DOES-NOT-EXIST :CREATE
is both reasonable and appropriate. In fact, I would advocate any programmer
write this even if the proposed change were adopted.
I do not think that it is the purpose of argument defaults to let you just
fail to specify their value when they are coincidentally what you would
have supplied. That is, I would sometimes suggest explicitly supplying the
same value as would be defaulted if that value is important to you and that
fact might be interesting to your reader.
I do think that The Purposes of argument defaults include:
* to let one be deliberately vague about a particular feature.
(I don't think the test case Skona is suggesting is a case where
the programmer should be vague. Indeed, I think it is one where
she has as much as said that the programmer wanted to get a
specific, non-vague thing. To get it, the programmer has only
to ask for it explicitly.)
* to let one omit information that seems irrelevant, and yet to
have something reasonable occur in the case where it turned out
to be relevant.
(In the case in question, if the user omitted the :IF-DOES-NOT-EXIST
case, it seems likely that they didn't think this case through. I've
discussed the consequences of this above, but I think the current
interpretation is as good as the one being proposed. If they did
think the case through, I believe that is tantamount to declaring
it `relevant' and they should have explicitly specified the option.)
Given that the change neither extends the power of the language nor
encourages the programmer to write cleaner code (at least, by the metrics
I've stated above), I can't endorse it. If a stronger argument is advanced,
I will, of course, reconsider my position based on that argument.
In either case, I am happy to see it presented to the full committee
for a vote anyway if Skona wants it to (with some reworking of the
rationale and some -very- trimmed down version of this dissenting
commentary).
∂09-Nov-87 1955 CL-Cleanup-mailer DECLARE-MACROS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 87 19:55:09 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 275963; Mon 9-Nov-87 22:55:42 EST
Date: Mon, 9 Nov 87 22:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <871109-155705-4230@Xerox>
Message-ID: <871109225531.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 9 Nov 87 15:56 PST
From: Masinter.pa@Xerox.COM
I responded to Moon's suggestions for wording correction. I added an
explicit endorsement at the end.
Looks ok.
In the interest of shortening the issue, I removed the argument about
destructive MACROEXPAND hooks, which, I think, is more controversial
than the support that it raises.
As it happens, it's the issue which mattered the most to me personally --
just because it upsets my sense of order and makes me generally uneasy
when I think about it, I guess. But since the proposal is likely to pass
anyway and since the issue is still alluded to under adoption cost, I guess
I can live with this "simplification".
In order to avoid the controversy of what is a declaration, a declare
expression, a declare form, or a list whose car is DECLARE, I reworded
the proposal to be more explicit as to the intent, which is to negate
one specific paragraph in CLtL.
Looks ok.
I run some risk of making things worse, at least in your eyes, so you
might want to cast yours on the PROPOSAL section and respond to me if
you are unhappy.
Looks ok.
[Proposal omitted.]
I'll endorse DECLARE-MACROS:FLUSH (Version 2) as is.
∂10-Nov-87 1220 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 12:19:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 87 12:18:43 PST
Date: 10 Nov 87 12:18 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 9 Nov 87 20:01 EST
To: CL-Cleanup@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
Hornig@ALDERAAN.SCRC.Symbolics.COM
Message-ID: <871110-121843-5449@Xerox>
Well, in my attempt to summarize the discussion, I apparently botched
it. In re-reading it, I don't think I did justice to the summary of the
alternative view. However, despite a number of editing errors and
typo's, I think "thoroughly garbled" is a bit strong.
The reason there is no text under the Rationale heading is that the text
that occured in version 1 was moved into the discussion and aesthetic
sections. I agree the proposals read better if the Rationale header
includes a summary of what is to come. I would summarize the Rationale
is that this is the simplest and most consistent of the alternatives
considered. The endorsement summary was removed because enough
arguments and new evidence and test cases had arisen that it would have
been presumptuous to copy an endorsement from a previous proposal into a
rewriting.
I did review all of the mail before preparing the latest version. I read
carefully David's original arguments and the responses. I don't see any
need to reiterate them, but it would be useful to respond to the
additional comments which were posted since. In particular, the
original argument (unless this is an error, it is possible to construct
non-abortable loops) had two serious rebuttals (independent of this
issue, it is possible to construct non-abortable loops; sometimes users
*want* to create non-abortable loops).
I agree to postpone this issue for the next round; if anyone would like
a copy of the previous mail on the topic (I have about 25 messages
saved) let me know and I'll make it available.
The mail I have says that Pitman, Daniels, Fahlman, Ram, Steele (and
myself) support the current proposal (modulo a few minor edits).
∂10-Nov-87 1255 CL-Cleanup-mailer Re: Issue: PATHNAME-SYMBOL (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 12:55:52 PST
Received: from Salvador.ms by ArpaGateway.ms ; 10 NOV 87 12:54:13 PST
Date: 10 Nov 87 12:53 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-SYMBOL (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 9 Nov 87 20:39 EST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871110-125413-5509@Xerox>
I don't want to appear capricious, but I'm finding that
PATHNAME-SYMBOL:NO fails to have sufficient reason for introducing an
incompatible change. Certainly, the original design of coercing symbols
as well as strings into pathnames is questionable, but, as long as we
are retaining some coercion, why change the coercions that are allowed?
This issue contrasts in an interesting way with FUNCTION-TYPE, where I
prefer removing all coercions; in this case, since some coercions are
being left (in particular, coercing from a string to a pathname),
shouldn't all "reasonable" coercions be allowed?
One definition for a "reasonable" coercion is one where there is a
simple way to convert from one type to another and alternative
conversions are considerably more complex. I think this holds for
symbol->pathname, symbol->string, string->pathname. The reason why
coercions need not be transitive is that following a->b->c is more
complex than either a->b or b->c.
(I'd also prefer to see that COERCE do explicitly what other functions
allow implicitly, e.g., (coerce "abc" 'pathname) = (pathname "abc"), but
that is certainly is another cleanup issue.
Version 3 of the proposal did not include an endorsement summary. So
far, Steele, Pitman, Moon explicitly endorsed PATHNAME-SYMBOL:NO, Eric
Benson argued against it.
∂10-Nov-87 1320 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 13:20:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 87 13:20:16 PST
Date: 10 Nov 87 13:20 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
In-reply-to: kempf%hplabsz@hplabs.HP.COM's message of Mon, 09 Nov 87
15:41:27 MST
To: kempf%hplabsz@hplabs.HP.COM
cc: cl-cleanup@sail.stanford.edu, kempf%hplabs@hplabs.HP.COM
Message-ID: <871110-132016-5562@Xerox>
Proposal form:
We need to decide on the name of this proposal. The mail messages have
had subject lines "TRACE Proposal" or "Issue: TRACE-FUNCTION-ONLY", but
the body of the proposal has said TRACE-CLOS. Since I've been filing it
under TRACE-FUNCTION-ONLY, I vote for changing the body to say
TRACE-FUNCTION-ONLY. (The proposal for dealing with SETF functions is
called SETF-FUNCTION-VS-MACRO, not SETF-CLOS.)
I'm a bit uneasy that some things appear under different categories than
I would have placed them (most of the discussion under Rationale is not
properly part of the rationale of this proposal but rather some
additional considerations). The discussion of Conversion Cost seems to
be a discussion of Adoption Cost instead. Conversion Cost is supposed to
address the cost to users of converting their code to deal with a
proposal, rather than to the Lisp system implementors. I think the
current practice and extensions to TRACE employed by various
implementations should at least be alluded to under Current Practice.
I don't know why the fact that this is a part of the environment rather
than the language makes the burden of adoption cost any less.
("However, compatibility with existing implementations seems less of an
issue here, since TRACE is more a part of the environment.")
∂10-Nov-87 2348 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 23:48:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 87 23:49:24 PST
Date: 10 Nov 87 23:48 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: masinter.pa@Xerox.COM
Message-ID: <871110-234924-6361@Xerox>
I rewrote this proposal with only the :KEYWORD option. I added an
endorsement. I added mention of the possibility of a registry in the
discussion. I rewrote some sections to avoid Kent's original
first-person phrasing. I reworded the proposal as a change to the
language rather than a change to CLtL.
I removed the wording in the Rationale which said "Since it's clear that
Common Lisp is not going to handle all of everyone's needs, one of the
most important things we can provide is a well-defined
conditionalization system to allow people to escape to native code."
since I disagree; I think of our work in CL-Cleanup as primarily
oriented toward minimizing the amount of #+ and #- that users need to
perform. Whether you agree or not, I think the proposal stands without
it.
!
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 03/01/87
Version 2 by Masinter 10-Nov-87
Problem Description:
No information is provided in the description of #+ and #- (pp. 358-359)
about what package the features are read on.
In some systems, the current package is used. Since there is no wording
in CLtL to the contrary, it's reasonable to assume that this would be
done, but a consequence of this is that you must be much more sensitive
to the package you're in at any given time when using #+ or #- even for
system-provided features. (This is a problem if the LISP package can
contain only the symbols in CLtL because system-provided features will
likely not have the names of symbols on LISP and hence will require
package prefixes. Having a symbol named LISP:SYMBOLICS or LISP:LUCID
would not be possible, so something like #+Symbolics would not be
possible; you'd have to write #+SYSTEM:SYMBOLICS or some such, which
might get a read error in a non-Symbolics implementation that didn't
export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This
means that package prefixes are rarely necessary in sharpsign
conditionals for system-provided features regardless of the current
package or restrictions about what may be in LISP. (For example, the
KEYWORD package can have any symbol so it's not a problem to push
:SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Specify that the default package while reading feature specs is the
keyword package. Other packages may be designated by use of explicit
package prefixes.
Symbols on *FEATURES* may be in any package but that in practice they
will mostly be on the keyword package because that's the package #+/#-
uses by default. If symbols in a package other than keyword appear on
*FEATURES*, they will be seen by #+/#- only if marked by explicit
package prefixes in the written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on
p. 448 is KEYWORD.
Rationale:
Making the behavior of #+ and #- well defined is important for people
writing portable code that manipulate *FEATURES* directly.
Current Practice:
Some implementations bind *PACKAGE* while reading feature specs and
others do not.
Adoption Cost:
Changes to implementations to make them conform to either of these
should be fairly minor if not trivial.
Benefits:
As currently specified, using #+ and #- in truly portable code can have
bootstrapping problems, since it is sometimes required to conditionally
set up *FEATURES* in different ways for different systems.
Conversion Cost:
Few changes to user code will be required; code that uses #+ and #- will
continue to work, although code that manipulates *FEATURES* directly may
require editing.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL or to certain
implementations.
Discussion:
The cleanup committee supports this proposal.
It might be reasonable to suggest that only vendors should add keyword
symbols to the *features* list, and that users should add features on
their personal packages so that collisions due to user applications were
less likely. This idea might be a subject of controversy though, so is
not part of this proposal.
It would be useful to create a non-binding registry of feature names
(and package names) already in use, so that Lisp implementors could pick
otherwise unused feature names, and users who wanted to write portable
code could know what feature names were preferred.
∂10-Nov-87 2359 CL-Cleanup-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 23:58:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 87 23:59:46 PST
Date: 10 Nov 87 23:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 4)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <871026-165748-2355@Xerox>
Dan Brotsky pointed out that the test case was missing an EXPORT. I added it.
I modified the Adoption Cost section to be more vague about the number of lines
this proposal requires changing.
I'm going up the list in reverse order. This is the first issue I've come to that seems
completely ready for release with no further discussion.
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate JonL's suggestions
Version 3 Masinter 26-Oct-87
Version 4 Masinter 10-Nov-87
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
SHADOW is said to take symbols as arguments, however only the print-name
is meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the
PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is already
present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as
well as symbols. The specification "the print name of each symbol is
extracted" is to be modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
;;; list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(export 'test-2::test (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when
calling the function USE-PACKAGE. The name conflict is between a symbol
directly present in the using package and an external symbol of the used
package. This name conflict may be resolved in favor of the symbol
directly present in the using package by making it a shadowing symbol.
For this to work, SHADOW must add the symbol to the
PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string
should also be accepted. This is particularly useful to avoid problems
when compiling code in one package environment and loading it into a
slightly different package environment, where the symbol that was
referred to at compile time may not be present at load time. This is
particularly important because the symbol referred to by the print name
may be changed by evaluation of the SHADOW form. A close reading of
CLtL shows that one can already use (shadow '#:bar) in place of (shadow
'bar), to achieve much the same effect as (shadow "BAR"). But the user
should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. Kyoto
Common Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when
the symbol is already present in the package. It seems likely that we
will find several implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Adoption Cost:
This should be a minor change to implementations that do not currently
work this way.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve
the name conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Conversion Cost:
Technically this would be an incompatible change to implementations that
do not already behave as proposed, however it is difficult to conceive
of a user program that would require any conversion to cope with the
change. Some users might want to remove kludges that were only necessary
to get around the former misbehavior of SHADOW.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying
the language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
The cleanup committee endorses this proposal.
∂11-Nov-87 0133 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 01:33:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 00:46:15 PST
Date: 11 Nov 87 00:46 PST
From: Masinter.pa@Xerox.COM
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM, Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <871111-004615-6413@Xerox>
(Dave, in looking over the mail on this, I see that we neglected to cc
you on our discussion. I intended to, but apparently forgot, to include
the original submitter in subsequent discussion.)
I've tried to respond to Moon's points. I was reluctant to add (at a
late date) the ability to coerce a list to a non-vector array and vice
versa, because there are several possible natural interpretations.
(E.g., should (COERCE '#2A((A B) (C D)) 'LIST) => '(A B C D) or '((A B)
(C D))? Rather than opening that can of worms unnecessarily, I thought
it best to stick to the problem at hand...
I don't think we've justified extending COERCE to allow it to *increase*
the rank; all of the arguments were addressed toward merely allowing
(COERCE <array> 'VECTOR). I changed point 1 to say this, hopefully less
ambiguously than before.
I agree with David's analysis of point 2 and removed it, (re)numbering
the subsequent points.
NREVERSE, NSUBSTITUTE were miscategorized. The (N)SUBSTITUTE-IF(-NOT)
functions were missing.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Common Lisp already provides a facility called "displaced arrays" which
can be used to overlay one array on top of a portion of another, even if
the two are of different ranks, so that the two share storage or use the
awkward convention of creating a displaced array to the operand.
However, creating a displaced array merely to perform FILL, REPLACE or
EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Generalize the definition of COERCE so that an array of any rank can
be coerced to type VECTOR or to type SEQUENCE. The result of (COERCE
<array> 'VECTOR) or (COERCE <array> 'SEQUENCE) when <array> is an array
of rank other than 1 is a vector displaced to the original array,
equivalent to
(MAKE-ARRAY (ARRAY-TOTAL-SIZE <array>)
:ELEMENT-TYPE (ARRAY-ELEMENT-TYPE <array>)
:DISPLACED-TO <array>).
2) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow
arrays of rank other than 1. These functions should treat array
arguments as vectors displaced to the array storage (in row-major
format). The affected functions are LENGTH, ELT, COUNT, FIND, POSITION,
SOME, EVERY, NOTANY, NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE,
SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
and (ELT A 7) should return the same element as (AREF A 0 1 0). :START
and :END keywords would be interpreted relative to the vector, as would
the results returned by POSITION and SEARCH.
3) Extend the definitions of sequence functions whose result should be
the same shape as but not necessarily EQ to some argument. These
functions should deal with array arguments by returning an array of the
same shape as the argument, and operate on their argument in row-major
order. The affected functions are SUBSTITUTE, NSUBSTITUTE, REVERSE,
NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
NSUBSTITUTE-IF-NOT and MAP.
4) Sequence functions that modify the number of elements in the array
remain unchanged: it is an error to pass arrays of rank other than 1.
(The functions are not extended because the shape would be undefined.)
The unaffected functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE,
REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a
sequence function, and it already has a well-defined behavior for
arrays. To test whether the arrays A and B, of different shapes, have
the same elements, one might write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low
adoption cost.
Adoption Cost:
This would involve a lot of changes to functions, but all of the changes
are likely to be minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back up
these proposed changes is already in place.
Benefits:
This proposal adds natural support for multi-dimensional arrays.
Currently, users must write nested DO loops every time they want to
perform an array operation equivalent to FILL, REPLACE, REDUCE, etc., or
else they build displaced vectors by hand and pass them to the sequence
functions when necessary. With this proposal,users of arrays do not have
to use home-grown utilities to duplicate functionality already
primitively provided to users of arrays. The sequence functions become
useful in a variety of new situations.
Conversion Cost:
This change is upward compatible; current user code should run
unmodified.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly
avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives
(which would be needed to take arbitrary k-dimensional slices out of
n-dimensional arrays, or to apply an operator across a specific
dimension of a multidimensional array), it requires just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what
follows is only a brief summary of the discussion.
An alternative considered was to only affect those functions which
didn't explicitly depend on the shape of the array; that is, to modify
COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE,
NSUBSTITUTE, and MAP, and expressly forbid arrays as arguments to other
sequence functions, including LENGTH, ELT, FIND, POSITION, REDUCE,
SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, as well as SUBSEQ,
COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some
hedging over REDUCE and FIND, which often have non-positional uses, were
considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's
been building displaced vectors to pass to sequence functions when
necessary and really dislikes it.
We considered but discarded as unworkable an alternative where POSITION
and FIND might deal with "positions" as lists of array subscripts.
Another alternative considered would be to only adopt the COERCE change,
and require users who want to operate on arrays explictly perform, e.g.,
(COUNT item (COERCE x 'SEQUENCE)). This alternative would have the
lowest adoption cost; perhaps some implementations could optimize such
coercions.
The general reason for opposing this change is that it adds more
mechanism than it is worth. The general reason for liking it is that it
adds generality at little cost.
∂11-Nov-87 0133 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 01:33:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 01:11:48 PST
Date: 11 Nov 87 01:11 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <871111-011148-6438@Xerox>
I tried to tighten the discussion section and respond to Moon's
comments. I rewrote the problem description to remove the claim that it
was impossible given the specified setf method for symbols. I'm happy
with Moon's arguments about the likelihood of user programs "copying"
LDB instead of the symbol method.
!
Issue: SETF-METHOD-FOR-SYMBOLS
References: CLtL pp. 105, 99. Issue: PUSH-EVALUATION-ORDER.
Category: CHANGE
Edit history: Version 1 Moon 21 Sep 87
Version 2 Masinter 23-Oct-87
Version 3 Masinter 11-Nov-87
Problem description:
The description of SETF in CLtL and various SETF methods are
inconsistent. The description on page 99 clearly requires side-effects
to be elaborated in left-to-right order; however, the combination of the
sample setf-method for LDB on p.106 and the sample setf-method for
symbols given on p. 105 results in incorrect order of evaluation.
Test Case A: Given
(LET* ((R (LIST 'A 1 'B 2 'C 3))
(S R))
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
If side-effects are elaborated in left-to-right order, the setq of R to
NIL should not affect the result, since it occurs after R is read and
before R is written, and therefore the value of both R and S should be
(A 1 B 6 C 3).
A typical result in an implementation that believes CLtL p.105 more than
CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).
Test Case B: Given:
(LET((A 0))
(INCF (LDB (BYTE 2 2) A) (SETQ A 2))
A)
Does this return 8, 10, or 2? If p. 99's description of order of
evaluation is correct, this should return 8.
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the example of the result of
(GET-SETF-METHOD 'FOO) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
(as currently described in CLtL) to return, for example,
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
Rationale:
The general principle mentioned on p.99 should override the specific
example on p.105. The latter is probably just a mistake.
Current practice:
Symbolics and Lucid return the incorrect result mentioned in the test
case A. (Symbolics plans to fix this in the next release.) Franz and
Xerox returns something else: R = nil and S = (a 1 b 6 c 3); Xerox
returns A=10 in Test Case B. HP Common Lisp produces the recommended
value.
Spice Lisp returns the recommended value for the test case A, even
though it uses the suggested value for the setf-method for symbols,
because the get-setf-method for GETF introduces additional temporary
bindings.
Adoption Cost:
SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some care
might be required in updating implementations. However, in some
implementations changing what get-setf-method returns when its argument
is a symbol is the only change required.
It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.
Cost of non-adoption:
Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.
Benefits:
Improved portability of Common Lisp programs.
Conversion Cost:
This change is incompatible because it changes the result of some forms
that are not erroneous. However, it's unlikely that very many users are
intentionally depending on the current behavior. In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.
Esthetics:
See "cost of non-adoption".
Discussion:
A specification of Common Lisp would do well to included some better
examples of precisely what is meant by the "`obvious' semantics"
mentioned on page 99.
This proposal is consistent with PUSH-EVALUATION-ORDER:ITEM in affirming
the left-right order of evaluation of subforms of generalized variable
access forms.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
However, we believe that user programs are much more likely to have
copied the setf method for LDB given on p.106 than the setf method for
symbols schematized on p.105, and this is the simplest change to achieve
compatibility and correct behavior.
∂11-Nov-87 0149 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 01:49:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 01:49:59 PST
Date: 11 Nov 87 01:49 PST
From: Masinter.pa@Xerox.COM
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: various
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871111-014959-6472@Xerox>
I'm not sure where we stand as a group on this issue.
I'll first say that I think the Cleanup committee is not an unreasonable
place to raise issues which might be construed as changing the goals of
Common Lisp. It also seems that X3J13 cannot really deal with general
issues without having some specific examples to deal with, and
REMF-DESTRUCTURING-UNSPECIFIED is a useful precedent.
You may recall the rather painful and lengthy debate on the charter
statement at an early X3J13 meeting, which was trying to get down the
exact wording of what we were trying to do here. Portability was
certainly one of the priorities, and performance of CL implementations
wasn't mentioned.
I'll summarize my position on various issues. A cell is "destroyed" if
its CAR and/or CDR are setf-d to unspecified values.
The following is my opinion; it is somewhere in between
MAKE-EXPLICITLY-VAGUE and MAKE-EXPLICITLY-DEFINED. I think it is
consistent (i.e., no less vague) than CLtL but allows for the
performance advantages that DLA claimed was the primary motivation for
the original proposal. (I reject the "bad programming practice to rely
on" argument; we can establish programming practice by saying what is
good and bad practice. It is bad programming language design to attempt
to disallow bad programs by making them non-portable.
(SETF (GETF place indicator) value)
is permitted to SETF the CADR of what
(GET-PROPERTIES place (LIST indicator)) would return
(if non-null) or to SETF place.
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In addition, the cells removed may be "destroyed".
(SETF (GET symbol indicator) value)
behaves exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
behaves exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence), (DELETE object sequence ...), (DELETE-IF test
sequence ...), (DELETE-IF-NOT test sequence ...), (DELETE-DUPLICATES
sequence ...), (NSUBSTITUTE new-object old-object sequence ...),
(NSUBSTITUTE-IF new-object test sequence ...), (NSUBSTITUTE-IF-NOT
new-object test sequence ...)
when sequence is a list may "destroy" sequence
(NCONC . lists)
is defined such that (NCONC x y) == (if (null x) y (progn (setf (cdr
(last x)) y) x))
(NRECONC list tail)
may "destroy" list.
(NBUTLAST list ...)
is permitted to SETF the tail of its argument list whose CDR is ...
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is only permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
all but the last argument may be destroyed.
∂11-Nov-87 0207 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 02:07:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 02:08:02 PST
Date: 11 Nov 87 02:07 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL (Version 2)
In-reply-to: Masinter.pa's message of 23 Jul 87 15:49 PDT
To: kempf%hplabsz@hp.com, kempf%hplabs@hp.com
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871111-020802-6488@Xerox>
The latest version of this proposal has a couple of errors. Functions do
not take &ENVIRONMENT arguments, so
(MAKE-LOAD-TIME-EVAL <quoted form> &ENVIRONMENT env) : function
cannot be correct.
The is a paren error in the Test Case:
(defmacro print-load-date (&environment env)
`(quote ,(make-load-time-eval '(format T "~A~%" (get-date) env))))
... which is really an example.
There was no discussion of this issue after the posting of Version 2 on
23 July. I think the cleanup committee endorses the proposal and it can
be released with only a few edits.
∂11-Nov-87 0217 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 02:17:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 02:17:11 PST
Date: 11 Nov 87 02:17 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL (Version 2)
In-reply-to: Masinter.pa's message of 23 Jul 87 15:49 PDT
To: kempf%hplabsz@hplabs.hp.com, kempf%hplabs@hplabs.hp.com
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871111-021711-6498@Xerox>
The latest version of this proposal has a couple of errors. Functions do
not take &ENVIRONMENT arguments, so
(MAKE-LOAD-TIME-EVAL <quoted form> &ENVIRONMENT env) : function
cannot be correct.
The is a paren error in the Test Case:
(defmacro print-load-date (&environment env)
`(quote ,(make-load-time-eval '(format T "~A~%" (get-date) env))))
... which is really an example.
There was no discussion of this issue after the posting of Version 2 on
23 July. I think the cleanup committee endorses the proposal and it can
be released with only a few edits.
----- End Forwarded Messages -----
∂11-Nov-87 0249 CL-Cleanup-mailer Issue status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 02:48:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 02:49:01 PST
Date: 11 Nov 87 02:48 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
subject: Issue status
cc: Masinter.pa@Xerox.COM
Message-ID: <871111-024901-6521@Xerox>
This is my current updated issue list.
Should we meet on Monday? How many of you will attend X3J13?
Annotations:
* (nearly) ready for release
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: Please reply.
~ Tabled until resubmitted, i.e., no immediate action proposed.
!
* Proposal format (Version 12, 23-Oct-87)
Ready for release
* AREF-1D (Version 6, 6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
Ready for release
~ ASSOC-RASSOC-IF-KEY (Version 1, 22 Apr 87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
* COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Ready for release
{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Await error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
% CONSTANT-SIDE-EFFECTS (not yet submitted)
(it is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Need volunteer to submit
% DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
* DECLARE-MACROS (Version 2, 9-Nov-87)
(Disallow macros expanding into declarations.)
Ready for release
% DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
Is all of this mechanism necessary?
% DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
% DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
% DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
* DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
(Documentation string is not evaluated.)
Submitted, no replies
Ready for release
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
% DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Need volunteer to submit.
DO-SYMBOLS-DUPLICATES (Version 2, 29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and
performance cost.
Needs rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
% EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
Need volunteer to submit.
~ EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, deal with #., #, changes
independently.
% EXPORT-COORDINATION (no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Looking for proposal to make package manipulation lexical.
{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
% FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument."
Need volunteer to write up.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
% FORMAT-COLON-UPARROW-SCOPE (not yet submitted)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion
* FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Ready for release
% FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer to write up.
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
* FUNCTION-TYPE (Version 7, 9-Nov-87)
(Change definition of FUNCTIONP, function type ...)
Discussed at X3J13, new proposal due.
Ready for release.
% FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
Need volunteer to submit.
% FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace
etc) Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
~ GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Ready for release.
{ IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
{ IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Ready for release after
change ((-keyword- -var-)) to ((-keyword- -var-) ...)
% LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
* LOAD-TIME-EVAL (Version 2, 17-JUL-87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
No discussion after Version 2.
Almost ready for release (paren error in example.)
% MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
re-extract from environment-arguments?
CLOS notes say they need this?
~ OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
* PATHNAME-STREAM (Version 5, 23-Oct-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Do synonym streams delegate PATHNAME?
What are the requirements on the pathname of a stream?
% PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
% PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components,
etc in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
~ PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal interaction
must or even ought to work."
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 4, 27-Oct-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
Awaiting rewrite of "cell" terminology.
~ PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
* PUSH-EVALUATION-ORDER (Version 3, 8-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
??? Ready for release?
REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
~ REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
* SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
???? Ready for release?
* SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
Ready for release
* SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
???? Ready for release?
* SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
???? Ready for release?
{ SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
~ SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
* SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 10-Nov-87)
(What package are *features* in?)
Register *features*?
???? Ready for release?
% SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
% STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must be initially bound to synonym streams to *TERMINAL-IO*; demote this to the level of an implementation suggestion. This is to allow flexibility of implementation, for example to allow UNIX redirection to win."
Need volunteer to submit
% STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc were
CLOS classes?
% STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
% SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
% TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
* TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
Needs minor corrections
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(what happens with non-local exits out of
UNWIND-PROTECT cleanup clauses?)
Not quite ready for release
∂11-Nov-87 0618 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 06:18:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 276944; Wed 11-Nov-87 09:18:34 EST
Date: Wed, 11 Nov 87 09:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871111-014959-6472@Xerox>
Message-ID: <871111091816.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 11 Nov 87 01:49 PST
From: Masinter.pa@Xerox.COM
...
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In addition, the cells removed may be "destroyed".
If we say this, I would prefer to say they must be destroyed -- specifically,
the car of both removed cells must be set to NIL. This would have the following
advantages:
* DLA would get his efficiency boost.
* Implementations would agree.
* The minimal usefulness of the defined behavior would tend to
actively thwart users taking any advantage of the cells in the
first place.
(SETF (GET symbol indicator) value)
behaves exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(NREVERSE sequence), (DELETE object sequence ...), (DELETE-IF test
sequence ...), (DELETE-IF-NOT test sequence ...), (DELETE-DUPLICATES
sequence ...), (NSUBSTITUTE new-object old-object sequence ...),
(NSUBSTITUTE-IF new-object test sequence ...), (NSUBSTITUTE-IF-NOT
new-object test sequence ...)
when sequence is a list may "destroy" sequence
...
You use this verb destroy a bunch, but I think it is the nature of the
original problem -- not the solution.
I feel that we should say very explicitly in the new spec that they may
only affect the cdr chain or that they may only affect the the cars of
the cells in the chain and must leave the cdr chain itself intact or
that they may affect either the cars or the cdrs in the chain. Verbs
like "destroy" should either be explicitly defined to mean one of these
very specific things in the new glossary, or should be avoided entirely.
I also feel that code portability will be affected unless we agree that
either the cars or the cdrs are what can change.
∂11-Nov-87 0844 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 08:43:41 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 277092; Wed 11-Nov-87 11:43:30 EST
Date: Wed, 11 Nov 87 11:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 3)
To: Masinter.pa@Xerox.COM
cc: CL-CLEANUP@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870723-155014-1175@Xerox>
Message-ID: <871111114311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Well, I apologize for remaining silent on this issue for this long, but
little things were nagging at me about this issue and I haven't had time
to express them. I just couldn't vote in favor of it in the form in
which it was presented even though I agree strongly with the idea that
we should provide such a facility.
I finally wrote the following variant of Kempf's proposal, which has some
fairly substantive differences. Hopefully by reading through this, it will
become obvious to you what the nature of my uneasiness is.
-----
Issue: LOAD-TIME-EVAL
References: #, (p356), EVAL-WHEN (pp69-70)
Category: ENHANCEMENT/CHANGE
Edit history: 06-Jun-87, Version 1 by James Kempf,
17-Jul-87, Version 2 by James Kempf,
11-Nov-87, Version 3 by Kent Pitman
Status: For Internal Discussion
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time). Unfortunately, however, no access to
this capability is available to programs which construct other
programs without going through the reader.
Also, CLtL is vague about whether the result of this early evaluation
is re-evaluated at runtime.
Proposal (LOAD-TIME-EVAL:FOR-EVALUATION-ONLY):
Define that
#,form
is permissible -only- in a for-evaluation position. Define it to be
equivalent to:
#.(MAKE-LOAD-TIME-EVAL 'form)
Add a new function MAKE-LOAD-TIME-EVAL, defined as follows:
MAKE-LOAD-TIME-EVAL form [Function]
Returns an object which remembers the given FORM and is specially
recognized by the interpreter and compiler (in a for-evaluation
position -only-) in the following way:
If the object is seen by the interpreter for the first time, the
FORM evaluated in a null lexical environment. The result of the
evaluation is cached for later use, and then returned as the
result of evaluating the object. If the object is later seen again
by the interpreter, the previously obtained result is immediately
retrieved and returned as the result of evaluating the object.
No re-evaluation occurs.
If the object is seen by the file compiler (eg, COMPILE-FILE) in
a for-evaluation position, the compiler processes FORM in such a way
as to arrange for its evaluation at load time in a null lexical
environment (independent of whether a value has already been cached
by the interpreter). At runtime, the result of that evaluation will
be treated as a literal constant.
If the object is seen by the runtime compiler (ie, COMPILE), the
compiler checks for a cached value which may have been produced by
the interpreter. If one is found, it is used. If no such value is
found, the runtime compiler will evaluate the FORM in a null
lexical environment and use that value. The value used will be
treated as a literal constant in the code which is produced.
Note that since some implementations are compiled-only (that is, they
implement their interpreter using a compiler pre-pass) and some are
interpreted-only (that is, they implement their compiler as a null
operation and use only an interpreter), the question of whether the
interpreter or the compiler will end up doing the processing is left
somewhat vague. The programmer may assume only that the given FORM
will be evaluated only once for each time it is loaded into a runtime
environment.
Test Cases:
(defmacro print-load-timestamp ()
`(print ,(make-load-time-eval '`(load-timestamp ,(incf *foo*)
,(get-universal-time)))))
(defvar *foo* 0)
(defun test-1 () (print-load-timestamp))
(test-1)
CLtL does not define this situation.
Under this proposal, this code would print
(LOAD-TIMESTAMP 1 <<a-universal-time>>)
at the time the test case is loaded, whether interpreted or compiled.
Subsequent calls to (TEST-1) should print the identical expression.
(defun test-2 () (print #,'(+ 3 4)))
CLtL does not adequately define this situation.
Under this proposal, this would print (+ 3 4), whether interpreted
or compiled.
(defun test-3 () (print '#,'(+ 3 4)))
Under CLtL, this would print (+ 3 4).
Under this proposal, the behavior would be undefined.
Rationale:
By making the description of MAKE-LOAD-TIME-EVAL be defined only in a
for-evaluation situation, we eliminate the need for it to take an environment
argument in order to allow it to guess whether an interpreter-style or
compiler-style expansion is appropriate. A single expansion can be reliably
correct.
By making #, agree with MAKE-LOAD-TIME-EVAL in terms of where it may be used,
we simplify the description of the resulting language.
As discussed in more detail elsewhere in this proposal, the #, syntax is
currently only reliably useful -inside- quoted structure, but this is
unnecessarily complicated for most known uses. Since this proposal suggests
a meaning for #, only -outside- quoted structure, it is an incompatible change
but not one that will generally require vendors to immediately remove support
for existing code.
Current practice:
Although most implementations provide a substrate which would allow
program-mediated access to load time evaluation in some way, the language
only defines access through the sharpsign read syntax.
No implementation is required to support TEST-1. Probably none support it in
exactly the proposed form, though some may provide an analogous extension.
Most implementations pretend to support TEST-2, though they do not all agree.
Some compilers complain about the syntax of TEST-2, some arrange for a call
to it to print (+ 3 4), and some may arrange for a call to it to print the
result of evaluating (+ 3 4) -- ie, 7.
Most or all implementations are believed to handle TEST-3 correctly, printing
(+ 3 4).
Adoption Cost:
This proposal will require some implementations to change, but the cost of
changing should not be high.
A definition of MAKE-LOAD-TIME-EVAL which should suffice is:
(DEFVAR *SQUID* (MAKE-SYMBOL "SQUID")
"SQUID (Self-QUoting Internal Datum) is a Maclisp term.")
(DEFUN MAKE-LOAD-TIME-EVAL (OBJECT)
(LIST *SQUID* OBJECT NIL NIL))
The game then is to make the evaluator do something like:
(DEFUN SQUID-P (OBJECT) (AND (NOT (ATOM OBJECT)) (EQ (CAR OBJECT) *SQUID*)))
(DEFVAR *YUCK* (MAKE-SYMBOL "YUCK"))
(DEFUN *EVAL (OBJECT ENVIRONMENT)
(COND ...
((SQUID-P OBJECT)
(COND ((CADR OBJECT)
(IF (EQ (CADDR OBJECT) *YUCK*)
(ERROR "Does anyone think we should worry about this case?")
(CADDR OBJECT)))
(T
(SETF (CADDR OBJECT) *YUCK*)
(SETF (CADR OBJECT) T)
(SETF (CADDR OBJECT) (EVAL OBJECT)))))
...))
The compiler, of course, must use SQUID-P and something fairly analogous.
Cost of non-adoption:
There are numerous possible uses for this facility. Among them are:
* Version control and system building facilities.
* The Common Lisp Object System.
* Language translators which desire to emulate "linking".
While every implementation of Common Lisp could certainly provide an
implementation specific facility, portability would suffer.
Benefits:
Portability and extended language power. The nature of the extension is
such as to enable other extensions to be added more gracefully. The
Common Lisp Object System is a clear example.
Conversion Cost:
The change to #, is an incompatible one, but vendors would be free to
provide compatibility support for the old behavior for whatever period
they deemed appropriate.
In fact, the number of users of #, is likely to be quite small because
it is a somewhat obscure and hard-to-explain feature, so conversion cost
should not be a major issue.
Aesthetics:
This proposal clarifies and regularizes existing parts of the language.
Also, by adding program-accessible entry points to facilities already
provided in a more contrived way, it makes the language easier to use.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp.
The cleanup committee seems to generally approve of the idea of a
load-time-eval capability, but a number of the details seem to need
ironing out.
Pitman supports this re-draft of Kempf's proposal, but doesn't expect
this to be the last word on the subject. Surprises are welcome.
∂11-Nov-87 0929 CL-Cleanup-mailer Issue status
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 09:28:26 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 277143; 11 Nov 87 12:29:12 EST
Date: Wed, 11 Nov 87 12:28 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue status
To: CL-Cleanup@SAIL.Stanford.Edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <871111-024901-6521@Xerox>
Message-ID: <871111122853.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
For my personal sanity, I was forced to reformat the status list into an
intelligible format -- I just couldn't deal with the `paging' that came
from having terminated issues sorted in with things that were still active.
Here's my re-ordered list for others who think like me (although surely
there are no such people on this list :-). These are formatting changes
only. I didn't move anything between categories, and any editorializing
I have will follow under separate cover. -kmp
-----
Ready: Expecting to be released at next meeting.
- Proposal format (Version 12, 23-Oct-87)
Ready for release
- AREF-1D (Version 6, 6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup 6Jul.
Ready for release
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Ready for release
- DECLARE-MACROS (Version 2, 9-Nov-87)
(Disallow macros expanding into declarations.)
Ready for release
- DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
(Documentation string is not evaluated.)
Submitted, no replies
Ready for release
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Ready for release
- FUNCTION-TYPE (Version 7, 9-Nov-87)
(Change definition of FUNCTIONP, function type ...)
Discussed at X3J13, new proposal due.
Ready for release.
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Ready for release.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Ready for release after
change ((-keyword- -var-)) to ((-keyword- -var-) ...)
- LOAD-TIME-EVAL (Version 2, 17-JUL-87)
(New function/macro/special form for evaluation when compiled file
is loaded?)
No discussion after Version 2.
Almost ready for release (paren error in example.)
- PATHNAME-STREAM (Version 5, 23-Oct-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Do synonym streams delegate PATHNAME?
What are the requirements on the pathname of a stream?
- PUSH-EVALUATION-ORDER (Version 3, 8-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
??? Ready for release?
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
???? Ready for release?
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
Ready for release
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
???? Ready for release?
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
???? Ready for release?
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 10-Nov-87)
(What package are *features* in?)
Register *features*?
???? Ready for release?
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
Needs minor corrections
Active: Being discussed, but not expected to be ready in time.
- DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
Is all of this mechanism necessary?
- DO-SYMBOLS-DUPLICATES (Version 2, 29-May-87)
(Can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Needs more information on implementation and performance cost.
Needs rewrite: flush :ALLOWED option, rewrite :ADD-KEYWORDS to
make default for :ALLOW-DUPLICATES as NIL., conversion cost => nil.
Not ready for release.
- PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
- PROCLAIM-LEXICAL (Version 4, 27-Oct-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
Awaiting rewrite of "cell" terminology.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
Not quite ready for release
Tabled: Awaiting new proposal.
- ASSOC-RASSOC-IF-KEY (Version 1, 22 Apr 87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
- EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, deal with #., #, changes independently.
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal interaction
must or even ought to work."
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
Non-Existent: Awaiting writer.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Need volunteer to submit.
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Need volunteer to submit.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
Need volunteer to submit.
- EXPORT-COORDINATION (no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Looking for proposal to make package manipulation lexical.
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FORMAT-COLON-UPARROW-SCOPE (not yet submitted)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer to write up.
- FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
Need volunteer to submit.
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
re-extract from environment-arguments?
CLOS notes say they need this?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must
be initially bound to synonym streams to *TERMINAL-IO*; demote
this to the level of an implementation suggestion. This is to
allow flexibility of implementation, for example to allow UNIX
redirection to win."
Need volunteer to submit
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
Hold: Awaiting action from another committee.
- COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Await error proposal
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
- IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
- IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
Approved: No further action pending.
- COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
∂11-Nov-87 1020 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 10:20:30 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 10:16:31-PST
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 08:37:58 PST
Received: from hplabsz.hpl.hp.com by hplms2.HP.COM; Wed, 11 Nov 87 08:37:34 pst
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Wed, 11 Nov 87 09:37:09 pst
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabs@hplabs.hp.com
Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
X-Mailer: mh6.5
In-Reply-To: Your message of 10 Nov 87 13:20:00 -0800.
<871110-132016-5562@Xerox>
Date: Wed, 11 Nov 87 09:37:06 MST
Message-Id: <7575.563647026@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
> Proposal form:
> We need to decide on the name of this proposal. The mail messages have
> had subject lines "TRACE Proposal" or "Issue: TRACE-FUNCTION-ONLY", but
> the body of the proposal has said TRACE-CLOS. Since I've been filing it
> under TRACE-FUNCTION-ONLY, I vote for changing the body to say
> TRACE-FUNCTION-ONLY. > (The proposal for dealing with SETF functions is
> called SETF-FUNCTION-VS-MACRO, not SETF-CLOS.)
This change sounds fine.
> I'm a bit uneasy that some things appear under different categories than
> I would have placed them (most of the discussion under Rationale is not
> properly part of the rationale of this proposal but rather some
> additional considerations). The discussion of Conversion Cost seems to
> be a discussion of Adoption Cost instead. Conversion Cost is supposed to
> address the cost to users of converting their code to deal with a
> proposal, rather than to the Lisp system implementors. I think the
> current practice and extensions to TRACE employed by various
> implementations should at least be alluded to under Current Practice.
I have no problem with this.
> I don't know why the fact that this is a part of the environment rather
> than the language makes the burden of adoption cost any less.
> ("However, compatibility with existing implementations seems less of an
> issue here, since TRACE is more a part of the environment.")
This was in response to a suggestion by Dave Moon, but I have no objection
if it is removed.
To save time, could you fold these changes into the final document? Thanks.
jak
∂11-Nov-87 1213 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 12:13:38 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 NOV 87 12:13:56 PST
From: MASINTER.PA@Xerox.COM
Date: 11 Nov 87 12:10:09 PST
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 11 Nov
87 09:18 EST, <871111091816.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871111-121356-7511@Xerox>
I was using the word "destroy" in the sense that it is used in CLtL. To
destroy a cell means to possibly replace its CAR and/or CDR with
unspecified values. To destroy a list sequence is to replace the CAR or
CDR of any tail of the list with unspecied values.
I don't think requiring destroyed cells to be smashed with NIL will
solve any particular problems. It won't improve the style of any
program, and won't allow any implementation to be more efficient.
∂11-Nov-87 1224 CL-Cleanup-mailer Re: Issue status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 12:24:51 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 NOV 87 12:25:33 PST
From: MASINTER.PA@Xerox.COM
Date: 11 Nov 87 12:21:46 PST
Subject: Re: Issue status
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 11 Nov
87 12:28 EST, <871111122853.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <871111-122533-7526@Xerox>
Thanks for sorting them. I'll keep them in those categories.
∂11-Nov-87 1245 CL-Cleanup-mailer Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 12:45:32 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 277417; Wed 11-Nov-87 15:46:02 EST
Date: Wed, 11 Nov 87 15:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <871111-121356-7511@Xerox>
Message-ID: <871111154545.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 11 Nov 87 12:10:09 PST
From: Masinter.PA@Xerox.COM
I was using the word "destroy" in the sense that it is used in CLtL. ...
Is it actually defined or just used in a seemingly consistent way. No offense
meant to Steele because the job he did was really excellent, but I hope we're
long past the days where we think that just because CLtL uses a particular
undefined term (even consistently) then the term is well-defined. (Of course,
it's possible I just didn't notice the definition...)
... I don't think requiring destroyed cells to be smashed with NIL
will solve any particular problems. It won't improve the style
of any program, and won't allow any implementation to be more
efficient.
I don't think this is clear.
There are many cases where people have `noticed' what REMPROP was returning
in Maclisp and figured out how to take advantage of it because it was an
`interesting' thing. If you smash something into usefulness, you reduce the
risk that people will `discover' [untrue] things about the language and rely
on them to be portable. If the desire to do non-portable things is reduced,
then I think this is equivalent to upgrading the overall level of style.
As for efficiency, we plan to do interesting things with our GC that takes
advantage of our being allowed to smash the car of the cell. But other
implementations might not have neat things they can do and yet users may
retain pointers to the cdr chain (with no intent to later inspect the
car of any cell in that chain). Since the cadr of the removed 2-list
is likely to sometimes contain large structures, forcing people to smash
a NIL into there may in fact improve the GC performance of some
implementations where the user would otherwise be retaining pointers to
live structure.
∂11-Nov-87 1338 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 13:38:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 13:38:32 PST
Date: 11 Nov 87 13:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of
Wed, 11 Nov 87 07:45:43 MST
To: CL-CLEANUP@Sail.stanford.edu
cc: sandra%orion@cs.utah.edu, Dave_Matthews%hpfclp@hplabs.HP.COM
Message-ID: <871111-133832-7666@Xerox>
I propose we meet Monday from 10-12. I hope we can get a meeting room
for that time. There are other committees meeting Monday afternoon;
also, we can decide which issues we want to distribute on Tuesday and
get them copied if we have them ready by noon.
Larry
∂11-Nov-87 1549 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 15:49:02 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 11 Nov 87 18:49:34 EST
Received: by kali.think.com; Wed, 11 Nov 87 18:50:01 EST
Date: Wed, 11 Nov 87 18:50:01 EST
From: gls@Think.COM
Message-Id: <8711112350.AA12611@kali.think.com>
To: Masinter.pa@xerox.com
Cc: CL-CLEANUP@sail.stanford.edu, sandra%orion@cs.utah.edu,
Dave_Matthews%hpfclp@hplabs.hp.com
In-Reply-To: Masinter.pa@xerox.com's message of 11 Nov 87 13:38 PST <871111-133832-7666@Xerox>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
Date: 11 Nov 87 13:38 PST
From: Masinter.pa@xerox.com
I propose we meet Monday from 10-12. I hope we can get a meeting room
for that time. There are other committees meeting Monday afternoon;
also, we can decide which issues we want to distribute on Tuesday and
get them copied if we have them ready by noon.
Larry
Oh, foo. I thought we would meet in the afternoon (perhaps with
no justification) and arranged my airplanes accordingly.
--Guy
∂11-Nov-87 1644 CL-Cleanup-mailer meeting time
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 16:43:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 87 16:38:01 PST
Date: 11 Nov 87 16:37 PST
From: Masinter.pa@Xerox.COM
Subject: meeting time
To: CL-CLEANUP@sail.stanford.edu, sandra%orion@cs.utah.edu,
Dave_Matthews%hpfclp@hplabs.hp.com
Message-ID: <871111-163801-8089@Xerox>
I'm willing to change to meeting from 4 to 6 or even in the evening if
there are too many conflicts.
(I understand there is a meeting of the editorial committee at 2 and a
meeting of the character committee from 1:30 to 3:30, and I want to
avoid conflicts. Do any of you know if the editorial committee meeting
is scheduled to last for more than two hours?)
I'll can just have copies made of the issues that are ready or nearly
ready for release, and if there are any serious corrections or changes
to any of them, we can either not distribute them or else describe the
changes in the meeting itself.
∂11-Nov-87 1701 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:01:37 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 16:57:43-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:02:17 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:51:25 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:51:02 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:51:07 mst
Return-Path: <dcm@hpfcdcm>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS
X-Mailer: mh6.5
In-Reply-To: Your message of 11 Nov 87 13:38:00 -0800.
<871111-133832-7666@Xerox>
Date: Wed, 11 Nov 87 17:51:00 MST
Message-Id: <1821.563676660@hpfcdcm>
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Larry,
I think it would be reasonable to have an afternoon meeting. We
can have the copies made by a local company in the afternoon or
overnight rather than at HP. Unless you had a very small
document (< 50 pages) I wouldn't be able to get it printed here
anyway. Seems they are printing a large job, 400,000 pages, till
the middle of next week and it would be tough to get much of
their time. The CLOS committee is going to need outside print
anyway since they are going to have around 150 pages, so I've
made arrangements with a local printing firm that was recommended
by our copy center. We can turn the cleanup document over to
them in the late afternoon and have it by the next morning,
collated and stapled.
I'd already scheduled conference rooms for Monday afternoon only
so let me know if you would like me to make any changes.
Dave Matthews
∂12-Nov-87 1520 CL-Cleanup-mailer meeting time
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 15:20:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278443; Thu 12-Nov-87 18:20:28 EST
Date: Thu, 12 Nov 87 18:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: meeting time
To: Masinter.pa@Xerox.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU, sandra%orion@cs.utah.edu, Dave_Matthews%hpfclp@hplabs.hp.com
In-Reply-To: <871111-163801-8089@Xerox>
Message-ID: <19871112231952.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I can meet any time on Monday.
∂12-Nov-87 1537 CL-Cleanup-mailer Re: Issue: PATHNAME-STREAM (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 15:37:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278455; Thu 12-Nov-87 18:36:51 EST
Date: Thu, 12 Nov 87 18:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-STREAM (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871109-131311-3795@Xerox>
Message-ID: <19871112233625.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 Nov 87 13:12 PST
From: Masinter.pa@Xerox.COM
I'd like to have this issue address in more detail what the "pathname"
of a stream is and can be expected to do; I think that elucidating what
we expect out of a pathname will help decide cases like synonym streams.
I disagree. I think the issue is deciding what synonym streams are, not
deciding what pathnames are. This is the same issue we had on the Common
Lisp mailing list long enough ago that I don't think it got into the
cleanup committee, where for some reason people seemed to be unable to
agree what CLOSE of a synonym stream means. Since there is that big issue,
and since no one else is responding, maybe that means this seemingly
very simple issue is actually intractable.
∂12-Nov-87 1704 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:03:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187844; Thu 12-Nov-87 20:03:50 EST
Date: Thu, 12 Nov 87 20:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
In-Reply-To: <871109-161932-4273@Xerox>
Message-ID: <19871113010337.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 Nov 87 16:19 PST
From: Masinter.pa@Xerox.COM
I'm a little uneasy about "Explicitly state that for the macros
CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
where CLtL specifies to the contrary."
I was trying to complete the set of references to macros affected by the
proposal, but I agree that this wording is poor. I'm not sure what to
replace it with, though.
I think that we also have to be careful about the following: suppose a
user defines
(defmacro wrong-order (x y) `(get ,y ,x))
If the user writes (push a (wrong-order (frob) (baz)))
are we willing to guarantee that "the subforms of the macro call
(including but not limited to subforms of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program. "?
Good point, and note that the same issue arises for
(setf (wrong-order (frob) (baz)) 1), so this point in no way shoots down
what we originally set out to do on the PUSH-EVALUATION-ORDER issue.
A more complicated version of wrong-order, for example, one with a loop
in it, would make it impossible to guarantee that statement. So we have
to change the statement. Ick. I think what we mean is that evaluation of the direct subforms
of the macro call and of generalized-variable references in the macro
call is ordered, but evaluation of subforms of those subforms is determined by the
recursive evaluation process as normal. I'd have to think about this more
to see if this is the best way to say it, it doesn't strike me as a model
of clarity.
Similarly if the user writes an "incorrect" setf-method, e.g.,
(defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z))
This is not an issue since CLtL p.103 says "This binding permits the
body forms to be written without regard for order-of-evaluation issues."
Of course a user could write an incorrect define-setf-method.
I wish this weren't so sticky. . . .
Me too. I think it's inherent in defining the order of evaluation of
things that aren't functions, so there's no easy answer.
∂12-Nov-87 1705 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187819; Thu 12-Nov-87 18:42:39 EST
Date: Thu, 12 Nov 87 18:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
To: kempf%hplabsz@hplabs.HP.COM
cc: Masinter.pa@XEROX.COM, cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabs@hplabs.hp.com
In-Reply-To: <7575.563647026@hplabsz>
Message-ID: <19871112234202.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 11 Nov 87 09:37:06 MST
From: kempf%hplabsz@hplabs.HP.COM
> I don't know why the fact that this is a part of the environment rather
> than the language makes the burden of adoption cost any less.
> ("However, compatibility with existing implementations seems less of an
> issue here, since TRACE is more a part of the environment.")
This was in response to a suggestion by Dave Moon, but I have no objection
if it is removed.
That's conversion cost. There is less burden on users when we incompatibly
change something that they (relatively rarely) type in by hand, than when we
incompatibly change something that appears in their programs. I hope everyone
agrees with this, once they understand what it says, it's not a profound point.
∂12-Nov-87 1705 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187823; Thu 12-Nov-87 18:48:57 EST
Date: Thu, 12 Nov 87 18:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871111114311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871112234843.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Kent, I think the change from #, only being allowed inside constants to
#, only being allowed as a form is completely backwards. It's an
unnecessary incompatible change, invites the question of why we bother
having a reader syntax for #, when it could just as well be a macro that
evaluates its subform only the first time it is called (with an
optimization to evaluate it at load time rather than on first call), and
appears to do violence to the relationship between #, and #.. I don't
favor your version of the proposal.
I wasn't able to figure out what else your uneasiness might have been,
if there was more than the constant-versus-form issue.
∂12-Nov-87 1815 CL-Cleanup-mailer Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187819; Thu 12-Nov-87 18:42:39 EST
Date: Thu, 12 Nov 87 18:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
To: kempf%hplabsz@hplabs.HP.COM
cc: Masinter.pa@XEROX.COM, cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabs@hplabs.hp.com
In-Reply-To: <7575.563647026@hplabsz>
Message-ID: <19871112234202.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 11 Nov 87 09:37:06 MST
From: kempf%hplabsz@hplabs.HP.COM
> I don't know why the fact that this is a part of the environment rather
> than the language makes the burden of adoption cost any less.
> ("However, compatibility with existing implementations seems less of an
> issue here, since TRACE is more a part of the environment.")
This was in response to a suggestion by Dave Moon, but I have no objection
if it is removed.
That's conversion cost. There is less burden on users when we incompatibly
change something that they (relatively rarely) type in by hand, than when we
incompatibly change something that appears in their programs. I hope everyone
agrees with this, once they understand what it says, it's not a profound point.
∂12-Nov-87 1815 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187827; Thu 12-Nov-87 19:21:17 EST
Date: Thu, 12 Nov 87 19:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Dave.Touretzky@C.CS.CMU.EDU
In-Reply-To: <871111-004615-6413@Xerox>
Message-ID: <19871113002102.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks good.
An obvious question that is going to arise is why did we define
(COERCE array 'SEQUENCE) to be (MAKE-ARRAY ... :DISPLACED-TO array)
rather than (CONCATENATE 'VECTOR array). In researching this I note
that it's pretty hard to tell from CLtL whether the other sequence
coercions are required to allocate new storage, or are allowed to share
existing storage, when they don't just return the argument. The word
"copy" is used in an off-hand remark, and I had always assumed without
thinking about it that COERCE was a copying operation, but CLtL never
actually says whether or not the result is allowed to share storage with
the argument, when they are not identical.
I imagine that unlike any other use of COERCE, our proposed
(COERCE array 'SEQUENCE) is -required- to share storage with the
argument, so that SETF of ELT may be used on the result, causing the
elements of the original argument to be affected. If true, we certainly
should put in a sentence or two of rationale to forestall questions.
This should both explain that we did it this way not just for "efficiency",
but so the user could rely on side-effects propagating from the vector
back to the array, and also say something about the relation of this to
the vagueness of the other sequence coercions.
This raises the question, why is COERCE really in this proposal anyway?
It almost seems to be there only to support the remark at the end about
how the whole proposal could have been replaced with a proposal just to
extend COERCE, but we chose not to do that. Maybe Dave T can comment on
the reasons for including COERCE.
∂12-Nov-87 1815 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:05:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187823; Thu 12-Nov-87 18:48:57 EST
Date: Thu, 12 Nov 87 18:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871111114311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871112234843.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Kent, I think the change from #, only being allowed inside constants to
#, only being allowed as a form is completely backwards. It's an
unnecessary incompatible change, invites the question of why we bother
having a reader syntax for #, when it could just as well be a macro that
evaluates its subform only the first time it is called (with an
optimization to evaluate it at load time rather than on first call), and
appears to do violence to the relationship between #, and #.. I don't
favor your version of the proposal.
I wasn't able to figure out what else your uneasiness might have been,
if there was more than the constant-versus-form issue.
∂12-Nov-87 1815 CL-Cleanup-mailer Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 17:03:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187844; Thu 12-Nov-87 20:03:50 EST
Date: Thu, 12 Nov 87 20:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PUSH-EVALUATION-ORDER (Version 3)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
In-Reply-To: <871109-161932-4273@Xerox>
Message-ID: <19871113010337.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 Nov 87 16:19 PST
From: Masinter.pa@Xerox.COM
I'm a little uneasy about "Explicitly state that for the macros
CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
where CLtL specifies to the contrary."
I was trying to complete the set of references to macros affected by the
proposal, but I agree that this wording is poor. I'm not sure what to
replace it with, though.
I think that we also have to be careful about the following: suppose a
user defines
(defmacro wrong-order (x y) `(get ,y ,x))
If the user writes (push a (wrong-order (frob) (baz)))
are we willing to guarantee that "the subforms of the macro call
(including but not limited to subforms of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program. "?
Good point, and note that the same issue arises for
(setf (wrong-order (frob) (baz)) 1), so this point in no way shoots down
what we originally set out to do on the PUSH-EVALUATION-ORDER issue.
A more complicated version of wrong-order, for example, one with a loop
in it, would make it impossible to guarantee that statement. So we have
to change the statement. Ick. I think what we mean is that evaluation of the direct subforms
of the macro call and of generalized-variable references in the macro
call is ordered, but evaluation of subforms of those subforms is determined by the
recursive evaluation process as normal. I'd have to think about this more
to see if this is the best way to say it, it doesn't strike me as a model
of clarity.
Similarly if the user writes an "incorrect" setf-method, e.g.,
(defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z))
This is not an issue since CLtL p.103 says "This binding permits the
body forms to be written without regard for order-of-evaluation issues."
Of course a user could write an incorrect define-setf-method.
I wish this weren't so sticky. . . .
Me too. I think it's inherent in defining the order of evaluation of
things that aren't functions, so there's no easy answer.
∂12-Nov-87 1843 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:42:44 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 278582; Thu 12-Nov-87 21:42:32 EST
Date: Thu, 12 Nov 87 21:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 3)
To: Moon@Stony-Brook.SCRC.Symbolics.COM
cc: KMP@Stony-Brook.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19871112234843.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <871112214214.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
(-: Well, I'm glad to see someone at least read the proposal. :-)
I'm not adverse to inviting the question. Why did we have a #, read
syntax? I can't think of any cases where it is necessary. Even in
cases where it occurs in embedded structure,
'(A B #,<expression>)
can be written
#,`(A B ,<expression>)
It's not even extra consing -- the loader's going to have to cons the
list anyway... Whether it's under user control seems to be a small
price to pay (unless I've confused myself somehow and there's more
going on here).
The examples from my Fortran->Lisp translator and from CLOS seem to both
be cases where the full power of #, is unnecessary. I'm willing to believe
there is another compelling case, but could not think of one the other
day when I tried.
I have no trouble keeping #, and #. straight, but I find that novices
I've taught get very confused by them. I think they are not as much alike
as people think (except as an accidental artifact of the cheapshot way
#, is typically implemented in the interpreter). I think the fact that
#, and #. cannot be distinguished in the interpreter is a major cause
of the confusion.
I -like- the idea that
(CADDR (CADDR (CADR '#'(LAMBDA (X) (+ X #,(SQRT 2))))))
should return #,(SQRT 2) rather than 1.4142135 because it might be that
my plans were to write the code back out and compile it in another
implementation with larger floating point precision. I want the #,
stuff processed at semantic analysis time even in the interpreter, never
at read time. Just because I READ something does not mean I plan to EVAL
it right away. That's the problem.
If you didn't process it at read time though, since there are still
holdouts who think you can write an interpreter which does no semantic
pre-pass, then executing QUOTE becomes very expensive (because you have
to check it for #, objects). So I expect people would object. So I'm
proposing not putting #, in QUOTE rather than proposing that EVAL work
harder when it finds a QUOTE expression. Am I missing something?
I kinda think that what I'm proposing is simpler (albeit incompatible).
I'm curious whether you disagree that this is simpler, and whether you
can show why (allegedly) simpler doesn't cut it.
I thought about just hashing this out with you privately, but we might
as well get this all into the record...
∂12-Nov-87 1845 CL-Cleanup-mailer Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:45:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187832; Thu 12-Nov-87 19:34:50 EST
Date: Thu, 12 Nov 87 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871110-234924-6361@Xerox>
Message-ID: <19871113003437.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks ready to release to me, except for the following typo:
Adoption Cost:
Changes to implementations to make them conform to either of these
should be fairly minor if not trivial.
"either of these" is left over from when there were two proposals.
∂12-Nov-87 1845 CL-Cleanup-mailer Re: Issue: PATHNAME-SYMBOL (Version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:45:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187838; Thu 12-Nov-87 19:43:27 EST
Date: Thu, 12 Nov 87 19:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-SYMBOL (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871110-125413-5509@Xerox>
Message-ID: <19871113004315.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 10 Nov 87 12:53 PST
From: Masinter.pa@Xerox.COM
I don't want to appear capricious, but I'm finding that
PATHNAME-SYMBOL:NO fails to have sufficient reason for introducing an
incompatible change. Certainly, the original design of coercing symbols
as well as strings into pathnames is questionable, but, as long as we
are retaining some coercion, why change the coercions that are allowed?
Three comments: CLtL is inconsistent, specifying symbol->pathname coercion
in some places but not in others. symbol->pathname coercion and
stream->pathname coercion cannot coexist, since CLtL pp.33-4 does not
require symbol and stream to be disjoint. Until we fix that, we can't
require both stream->pathname and symbol->pathname coercions in any
single function, and after we fix that, I don't see much advantage to
putting symbol->pathname coercion back in.
We could just drop the issue, of course; it's not like fixing this one
thing would make the pathname and stream portion of CLtL wonderfully
clear and unambiguous.
....
(I'd also prefer to see that COERCE do explicitly what other functions
allow implicitly, e.g., (coerce "abc" 'pathname) = (pathname "abc"), but
that is certainly is another cleanup issue.
I like this idea.
∂12-Nov-87 1845 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:45:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 187828; Thu 12-Nov-87 19:26:21 EST
Date: Thu, 12 Nov 87 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871111-011148-6438@Xerox>
Message-ID: <19871113002609.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Good enough, let's release it.
∂12-Nov-87 1848 CL-Cleanup-mailer Re: meeting time
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Nov 87 18:48:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 NOV 87 17:59:27 PST
Date: 12 Nov 87 17:59 PST
From: Masinter.pa@Xerox.COM
Subject: Re: meeting time
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 12 Nov 87 18:19 EST
To: CL-CLEANUP@SAIL.STANFORD.EDU, sandra%orion@cs.utah.edu
cc: Dave_Matthews%hpfclp@hplabs.hp.com
Message-ID: <871112-175927-1387@Xerox>
Given the number of issues we have to discuss, I think that we should
probably still plan to get together Monday AM from 10-12 AM, and if
necessary, have a followup session in the evening. The editorial
committee has some chance of running on beyond 4 PM.
I expect we can manage to get a meeting room in the hotel in the
morning.
Responses so far:
Kent = yes
David = yes
Larry = yes
Guy = would have to change travel plans
Sandra = probably not until 11.
I've not heard from anyone else.
∂14-Nov-87 0301 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Nov 87 03:01:44 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Sat 14 Nov 87 06:01:20-EST
Date: Sat 14 Nov 87 06:01:16-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Moon@SCRC-STONY-BROOK.ARPA
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19871113002102.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12350510652.7.TOURETZKY@C.CS.CMU.EDU>
Here is an explanation of the proper role of COERCE wrt arrays:
My "treat arrays as sequences" proposal was intended to do more than just
extend the applicability of the sequence functions to arrays. It was also
supposed to change the feel of arrays in the language, by implying that shape
isn't all that important; content is what matters.
To preserve the primacy of content, no matter what shape a sequence has (list,
vector, or n-dimensional array), we should be able to convert it to some other
shape and have the behavior of FIND, POSITION, LENGTH, ELT, etc., stay the
same. Looked at this way, it's perfectly obvious that if ARR is a 3x3 array,
then (COERCE 'LIST ARR) should return a nine element list, not a triple of
triples.
As for going from lists to arrays, I suggest that
(COERCE '(ARRAY dims) SEQ)
should be equivalent to
(REPLACE (MAKE-ARRAY 'dims) SEQ)
Note that SEQ may be any type of sequence, including an array; its elements
will be extracted in row-major order as if ELT were used. This definition also
preserves the results of ELT, FIND, POSITION, etc., as long as the source and
destination objects have the same LENGTH. If the source is longer, its
extra elements are lost; if the destination is longer, its extra elements
have undefined initial values.
-- Dave
-------
∂14-Nov-87 1340 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Nov 87 13:39:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279870; Sat 14-Nov-87 16:39:29 EST
Date: Sat, 14 Nov 87 16:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Dave.Touretzky@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12350510652.7.TOURETZKY@C.CS.CMU.EDU>
Message-ID: <19871114213919.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat 14 Nov 87 06:01:16-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Here is an explanation of the proper role of COERCE wrt arrays:
My "treat arrays as sequences" proposal was intended to do more than just
extend the applicability of the sequence functions to arrays. It was also
supposed to change the feel of arrays in the language, by implying that shape
isn't all that important; content is what matters.
Okay; this rationale should go into the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS proposal.
To preserve the primacy of content, no matter what shape a sequence has (list,
vector, or n-dimensional array), we should be able to convert it to some other
shape and have the behavior of FIND, POSITION, LENGTH, ELT, etc., stay the
same. Looked at this way, it's perfectly obvious that if ARR is a 3x3 array,
then (COERCE 'LIST ARR) should return a nine element list, not a triple of
triples.
Sure (ignoring wrong argument order to COERCE). Does this mean coercions from
non-vector arrays to lists should be put back into the proposal, but with a clear
description of what they do (unlike last time)?
As for going from lists to arrays, I suggest that
(COERCE '(ARRAY dims) SEQ)
should be equivalent to
(REPLACE (MAKE-ARRAY 'dims) SEQ)
Note that SEQ may be any type of sequence, including an array; its elements
will be extracted in row-major order as if ELT were used. This definition also
preserves the results of ELT, FIND, POSITION, etc., as long as the source and
destination objects have the same LENGTH. If the source is longer, its
extra elements are lost; if the destination is longer, its extra elements
have undefined initial values.
This is pretty hard to understand in light of the proposal that coercing an
array to a vector should share the storage, rather than creating a new vector
and using REPLACE to copy the elements. So is the semantics we are looking for
from COERCE to be sharing, copying, or undefined which?
∂14-Nov-87 1539 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 15:39:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 15:39:03 PST
Date: 14 Nov 87 15:38 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 3)
Message-ID: <871114-153903-3484@Xerox>
I fixed a nit in current practice, added an endorsement, and formatted
for release. This issue had somehow gotten dropped from the list of open
issues. The only mail after the last note were several "looks OK"
messages. I think this issue is ready for release.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue
of what happens if an argument to APPEND is a dotted list.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last list given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the
list to be returned.
In the degenerate case where there is no last cons (i.e., the argument
is NIL) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations
involving dotted lists. As such, deciding which to use is not just a
stylistic issue.
Test Case:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined
across implementations. This proposal upholds the apparent status quo in
a number of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Adoption Cost:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND or NCONC
incompatibly, the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow
things down.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and
NCONC can therefore produce dotted lists, some readers may have
(incorrectly) assumed that APPEND and NCONC can reliably deal in general
with dotted lists, something that doesn't appear to be guaranteed by a
strict reading. The proposed extension would happen to legitimize such
assumptions.
Conversion Cost:
This change is upward compatible.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list
may feel differently than those who view lists as a special kind of
dotted list.
Discussion:
The cleanup committee supports this extension.
∂14-Nov-87 1600 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 8)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Nov 87 15:59:56 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279950; Sat 14-Nov-87 18:59:46 EST
Date: Sat, 14 Nov 87 18:59 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871114185936.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: COMPATIBLE CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what this
new proposal calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in this proposal, but most are likely to be very close.
Adoption Cost:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little or no effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, such lists would have to be changed to be procedures
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be easily reconstructed if necessary).
Benefits:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The type hierarchy would be simplified.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
This proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
This proposal provides useful constraints which will be of aid to systems
doing automatic program analysis for the purpose of ``selective linking.''
Such tools may in turn make it possible to reduce the total size of a
delivered application program because only those Common Lisp functions
that are actually called need to be included.
Conversion cost:
The conversion cost associated with this proposal is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by this proposal, particularly the PROCEDURE
data type, can be converted to fairly lazily.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Aesthetics:
Adding the term ``procedure'' for what has previously been loosely
termed a ``true function'' is an aesthetic improvement because it gives
a name to a concept which had no formally defined name.
Discussion:
This proposal has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
There are additional issues which were formally attached to this proposal
and are now separated and should be brought up independently as another
issue. Key among them is the issue of whether implicit type coercion should
be done by functions like APPLY, FUNCALL, MAPCAR, and so on. Or, in the
terminology of this proposal, should those functions allow functions or
just procedures as arguments?
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Pitman supports this restructured proposal.
∂14-Nov-87 1606 CL-Cleanup-mailer Issue Status -- Summary of KMP's positions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Nov 87 16:06:33 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279956; Sat 14-Nov-87 19:06:01 EST
Date: Sat, 14 Nov 87 19:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue Status -- Summary of KMP's positions
To: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <871111122853.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <871114190552.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Sorry for the delay in all this. For those who are watching their mailboxes
up until they step onto the plane, here is my complete list of endorsements
on the issues which Masinter has labeled as candidates to go before X3J13.
In the case of all "No" votes, comments follow at the end detailing the
reason for my position.
Yes - Proposal format (Version 12, 23-Oct-87)
Yes - AREF-1D (Version 6, 6 JUL 87)
Yes - COLON-NUMBER (Version 1, 22-oct-87)
Yes - DECLARE-MACROS (Version 2, 9-Nov-87)
Yes - DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
Yes - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
No - FUNCTION-TYPE (Version 7, 9-Nov-87)
Yes - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
Yes - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
No - LOAD-TIME-EVAL (Version 2, 17-JUL-87)
No - PATHNAME-STREAM (Version 5, 23-Oct-87)
No - PUSH-EVALUATION-ORDER (Version 3, 8-Nov-87)
Yes - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
No - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
No - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
Yes - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
Yes - SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 10-Nov-87)
No - TRACE-FUNCTION-ONLY (Version 5, 9-Nov-87)
FUNCTION-TYPE (version 7)
I strongly object to the coupling of the FUNCTION type cleanup and the
implicit coercion. The former I support in principle and the latter I
am very unsure about. To clarify my views, I have distributed an
alternate proposal FUNCTION-TYPE:CONSERVATIVE as version 8 of this
proposal.
PATHNAME-STREAM (version 5)
I generally approve, but agree with Moon's concerns that the restrictions
on synonym streams are really gratuitous. Since this isn't a high priority
item, it can easily be deferred until the next meeting while we get this
worked out (if we can't work it out in person on Monday).
PUSH-EVALUATION-ORDER (version 3)
I'd be in favor of something cleaning up this wording, but the issues
which Masinter had raised had been nagging at me, too. I'd like to see
Moon draft a proposal that addresses these issues explicitly.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (version 4)
I can't support the GENERALIZE proposal; I want to return to the
MODIFIED proposal. My reasons are not those described in the summary as
the "majority reason for opposition." Rather, I am worried about the
fact that, as Touretzky himself pointed out, this proposal is aimed at
de-emphasizing the importance of the container shape. I think the
Lisp language has traditionally placed great importance on structural
shape and I am not happy to toss all that aside. I am happy to define
COERCE to allow coercion of matrices to vectors because that allows the
programmer to express explicit intent. I am also happy to allow implicit
coercion on operations that abstractly make sense without having to think
about shape changing. For now, though, that's as far as I'm willing to go.
SETF-FUNCTION-VS-MACRO (version 3)
I recognize this as an important concern and generally approve of making
a proposal along these lines, but there are a lot of particulars that I
am not sure about. If this goes to a vote now, it should mark me as
believing that it is premature. Among the issues I'd like more time to
think about are the choice of SETF as the symbol in the car of the name
list, the ability to supply a non-symbol to SYMBOL-FUNCTION, the syntax
implications for TRACE (since some implementations already define a
meaning for lists occurring in TRACE's argument positions).
TRACE-FUNCTION-ONLY (version 5)
Probably something along these lines is appropriate, but I would like
to see this tabled pending action on the SETF-FUNCTION-VS-MACRO issue
and on the CLOS spec. Further, I think it would be better to do a more
general review of what functionality TRACE might want to provide.
We risk getting ourselves in a situation where (TRACE ... list ...)
is overloaded in such a way that (TRACE (METHOD ...)) might mean either
to trace a function called METHOD or to trace a method. Although this
could be resolved using heuristics, it would be bad for us to muck
up the syntax so badly that we had to resort to heuristics to dig
ourselves out.
∂14-Nov-87 1616 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 16:15:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 16:15:39 PST
Date: 14 Nov 87 16:15 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 3)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <871114-161539-3514@Xerox>
In reviewing (and preparing hardcopies) of open issues, I discovered a
version 3 of this proposal that was never mailed. The notes say that
this issue is awaiting the error proposal, but frankly, I'm no longer
sure what interaction we might expect with the error proposal.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say
whether *BREAK-ON-WARNINGS* affects warnings output by the compiler. If
this is to be allowed, it should be an explicitly expressed part of the
contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these
functions are required to break on warnings if *BREAK-ON-WARNINGS* is
true (just as if it calls WARN).
Note: User interface commands provided by particular vendor
implementations which implicitly call COMPILE or COMPILE-FILE could bind
*BREAK-ON-WARNINGS* back to NIL if they felt it important to not break
for some reason relating to cultural compatibility. This would not
interfere with the proposed new semantics for the functions COMPILE and
COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when
warnings occur. If the compiler is permitted to warn (separate ballot
item), the effect of this variable on compiler warnings should be nailed
down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism
might have to be edited, but it would not be a major change.
Cost of not adopting this change:
Applications which want to programmatically deal with compiler
interactions would have
Benefits:
This would make the language definition more consistent by making it
less subject to special cases.
Conversion Cost:
Probably little or no user code would be affected by this change.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather
than the language.
We considered but rejected the notion of a separate
*compiler-break-on-warnings*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be
replaced in its entirity by a more structured signal/handler structure,
making this proposal moot.
∂15-Nov-87 0305 CL-Cleanup-mailer Issue: PATHNAME-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Nov 87 03:05:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 20:30:36 PST
Date: 14 Nov 87 20:30 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 6)
TO: CL-Cleanup@sail.stanford.edu
CC: MASINTER.pa@Xerox.COM
Message-ID: <871114-203036-3590@Xerox>
This version of the proposal allows pathname of synonym streams. We can
discuss it Monday.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: TRUENAME (p.413), PARSE-NAMESTRING
(p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 5 by Masinter 8-Oct-87 (explicitly only open)
Version 6 by Masinter 14-Nov-87
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a
pathname, but many sources or sinks of data that streams might be
connected to have no pathnames associated with them; for example,
streams created with MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many
such streams, there is no simple way to coerce such a stream to a
pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN or WITH-OPEN-FILE, or to synonym
streams whose symbol is bound to such a stream. It is an error to
attempt to obtain a pathname from a stream created with
MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM,
MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may
be, but is not required to be, the actual name of the file. The pathname
used is the same as would be returned by the PATHNAME function.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others return an empty pathname.
Some implementations do not return a meaningful value for PATHNAME of a
synonym stream.
Adoption Cost:
Implementations that do not currently handle PATHNAME of a synonym
stream will have to change to allow it. Otherwise, since the proposal
says only "is an error" rather than "signals an error", no
implementations other changes are necessary.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to
make them portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
The only point of disagreement on this proposal has been on the issue of
whether PATHNAME applies to synonym streams and returns the pathname of
the stream designated.
This version of the proposal says yes, because CLtL p 329 says about
synonym streams that "Any operations on the new stream ..." and does
not say anything about exceptions; earlier on the page the phrase
"synonym streams that pass all operations on" is used. This seems
fairly unambiguous, although the word "operations" is not defined. There
was a similar controversy about what CLOSE of a synonym stream means.
Note that there is currently no way portable to determine whether a
stream has a pathname available.
The entire PATHNAME section needs work to clarify the intent and enable
portable code. This is just a minor issue among the major ones.
This issue was previously endorsed at X3J13 conditional on clarifying
its intent about a "file" stream. The issue is now resolved except for
the handling of synonym streams.
∂15-Nov-87 0306 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Nov 87 03:05:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 21:04:54 PST
Date: 14 Nov 87 21:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PROCLAIM-LEXICAL (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <871114-210454-3591@Xerox>
JAR didn't come thru with a rewrite, so this is a last minute attempt to
construct one. What I mainly did was to omit the summary of Moon's
description of the "cell" model.
I'd like to present this to X3J13 even in its current interim state. We
will discuss it on Monday. (BTW, I intend to try to have a follow up
get-together Monday evening to go over and confirm the status of various
issues before the Tuesday meeting. Please check the hotel announcement
board (I assume there is one.)).
!
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37),
global variables (p68),
declaration specifiers (p157)
Category: ENHANCEMENT
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Problem Description:
The distinction between special and lexical variables is one of the more
confusing aspects of Common Lisp to those used to programming in Scheme.
There is no way to "undo" a SPECIAL proclaimation. Several aspects of
variable declarations (including whether the variable is a constant,
never rebound, and the like) are impossible in portable Common Lisp,
although they exist in several implementations. There are many
combinations of declarations allowed and not allowed.
CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
declared special, then a free reference to that name is a reference to
the special variable of that name, while a LAMBDA-binding of that name
indicates a binding of the lexical variable of that name. This would
mean that the following program is legal and that (TST) => 4:
(defun tst ()
(setq x 3)
(funcall (let ((x 4)) #'(lambda () x))))
However, if you feed this program to many Common Lisp compilers, a
warning message will be produced for the SETQ, saying something like
"Warning: X not declared or bound, assuming special." These warnings are
prominent; it is hard to believe that a program which elicited such
warning messages was "correct" in that implementation. This is a
disagreement between theory and practice.
Proposal (PROCLAIM-LEXICAL:ADD-LEXICAL-GLOBAL-CONSTANT):
Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT,
which are mutually exclusive with the SPECIAL declaration specifier.
All four may be used as proclamations; only SPECIAL and LEXICAL may be
used as declarations.
A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
CONSTANT. A name is said to be unproclaimed if it has not been
proclaimed to be any of these four.
A free reference or assignment to a name is an error if it is
unproclaimed and undeclared. (While we expect many programming
environments to allow such references in interactive programming, no
portable program should rely on free references to unproclaimed and
undeclared variables; compiler warnings when encountering them are
encouraged.)
A LAMBDA-binding in the absence of a declaration or proclamation binds
the lexical variable.
SPECIAL proclamations and declarations behave as defined in CLtL.
LEXICAL proclamations have no effect other than to make the name cease
to be unproclaimed. LEXICAL declarations shadow all enclosing
declarations and proclamation of any of these four types. LEXICAL
declarations have the same scoping rules as SPECIAL declarations.
GLOBAL proclamations make it an error to bind the name.
CONSTANT proclamations make it an error to bind the name and an error to
assign to the name.
DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
All keyword symbols are automatically proclaimed CONSTANT.
A free reference or assignment accesses the same value regardless of the
declaration or proclamation. This is called the global value. SPECIAL
binding alters the global value within its extent. (Multiple process and
multiple processor systems will have to make their own definitions of
the extent of a SPECIAL binding, as noted on p.38 of CLtL--this proposal
does not address that.)
There is only one global value for a name and it is used by all free
references, all free assignments, and all SPECIAL bindings.
It is an error to re-proclaim a variable to a different class. (We
expect this issue to revisited by the compiler committee, see discussion
below.)
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Note that the second element of the list is 2. That is because the
special binding of y changes the global value to 4, and the
declared-lexical reference to y accesses the global value, since there
is no surrounding lexical binding.
Current Practice:
No implementations have all of these proclaimations, although some have
LEXICAL and some have GLOBAL.
Cost of adopting change:
This proposal requires no fundamental changes to implementations; the
superficial changes are to expose all of the primitive concepts which
are already available to programmers. Compilers and interpreters will
need to support LEXICAL as a declaration. Checking that variables
proclaimed as GLOBAL are not rebound is possible but not required.
Referencing or assigning to an unproclaimed and undeclared name "is an
error", not "signals an error", which allows but does not require an
implementation to issue a warning. This is a change from current
language but does not mandate a change from current practice.
Benefits:
LEXICAL proclamation enhances compatibility with Scheme. GLOBAL
proclamation allows more efficient deep-bound implementations.
Cost of converting existing code:
This change is upward compatible and will affect no existing code except
for code-walkers and other programs that analyze code.
Aesthetics:
The distinction between special and lexical variables is one of the more
confusing aspects of Common Lisp to those used to programming in Scheme.
Some might prefer to have a separate syntax (instead of LET with special
declarations) to do dynamic bindings. However, for the most part, such
changes are orthogonal to the issues raised here.
Making primitive concepts explicitly available enhances aesthetics.
Discussion:
The original Common Lisp designers had difficulty with this issue;
putting in these features was part of the original intent, but time
didn't allow.
This proposal and many other proposals were discussed before this
version was arrived at.
There are four things that we would like to be able to proclaim about a
variable name (aside from TYPE):
- the default kind of binding if no declaration specifies which kind
- the name is not misspelled so don't warn about free references
- it is illegal to specially bind the global cell, because it is
a constant or because we want to optimize the performance of a
deep-binding implementation
- it is illegal to store into the global cell, because it is a constant
It is already possible in Common Lisp to proclaim all four of these
things, but some of them are mixed up with other concepts and not
separately available.
LEXICAL -- does nothing other than "not misspelled"
SPECIAL -- changes the default kind of binding from lexical to
special
GLOBAL -- makes it illegal to specially bind the global cell
CONSTANT -- makes it illegal to store into the global cell
CONSTANT implies GLOBAL because special-binding is storing
SPECIAL exists now. LEXICAL is its logical complement. CONSTANT exists
now but only buried inside the DEFCONSTANT macro. GLOBAL exists now but
only when implied by DEFCONSTANT. This proposal makes them all
explicitly available.
It is appropriate to make CONSTANT and GLOBAL proclamations change the
default kind of binding to "illegal", rather than leaving it lexical, to
avoid unforseen interactions.
Is it legal to change the proclaimation of a variable?
We want to allow a variable to be re-proclaimed for two reasons: to
correct proclaimations issued in error by the user without having to end
the Lisp session and start over, and to make it easier to merge programs
written by two different programmers. (The latter reason is suspect --
they shouldn't be in the same package anyway -- but there are times when
a quick fix is extremely handy.) On that other hand, we want the
compiler to be able to wire certain things in tight as a result of these
proclamations, so we need to make clear that if you proclaim something
to be GLOBAL, compile some code, then proclaim it to be SPECIAL and then
compile some more code the rebinds this variable, you may not get what
you expect. Same with changing the proclaimation of a constant.
The current considerations of the compiler committee might give a
framework for explaining what the rules are within that framework.
However, given the current state of things, it is best to say that it
"is an error" to re-proclaim a variable into a different class -- this
says that portable code cannot do this and count on the result -- but
that implementations are strongly urged to allow this re-proclamation as
a way of correcting erroneous proclamations, perhaps issuing a warning
or signalling a correctable error whenever a proclamation actually gets
changed.
∂15-Nov-87 0306 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Nov 87 03:06:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 21:16:10 PST
Date: 14 Nov 87 21:15 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
Message-ID: <871114-211610-3592@Xerox>
I merely appended the salient points of the discussion so far to the end of this.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Category: CLARIFICATION
Edit History: Jeff Peck, 15-Oct-1987, version 1.
Larry Masinter, 23-Oct-87, version 2.
David Moon, 8-Nov-87, version 3
Larry Masinter, 14-Nov-87, version 4
Not ready for release
Problem Description:
In the form: (PUSH (ref1) (CAR (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Other macros that manipulate generalized variables include ... PUSH....
Macros that manipulate generalized variables must guarantee the
`obvious' semantics: subforms of generalized-variable references
are evaluated ... in exactly the same order as they appear in
the *source* program."
That is, the sub-forms of Place should be evaluated once, left to right.
"The expansion of these macros must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the subforms of the
reference."
This paragraph and a discussion of SETF on the previous pages may also
be interpreted as requiring that *all* subforms of such macro calls
should be evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."
That is, the effect of the form (PUSH Item Place) is to evaluate
(SETF Place (CONS Item Place)) but with subforms of Place only evaluated
once.
Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form. Should the PUSH form have primacy over
the obvious SETF form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or
only those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized
variables, e.g., PUSHNEW, INCF, DECF, and those defined with
DEFINE-MODIFY-MACRO.
Test Case:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
If the subforms evaluate in left-to-right order, this will print 12
rather than 21.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
Explicitly state that for the macros that manipulate generalized
variables (PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF,
PSETF, SETF, POP, and those defined with DEFINE-MODIFY-MACRO) the
subforms of the macro call (including but not limited to subforms of the
generalized variable reference) are evaluated exactly as many times as
they appear in the source program, and in exactly the same order as they
appear in the source program. Explicitly state that for the macros
CHECK-TYPE, ASSERT, CTYPECASE, and CCASE, that rule is followed except
where CLtL specifies to the contrary.
In this context, "subform" means a form (that is, something whose
syntactic use is such that it will be evaluated) that is nested inside
another form. It does not mean any object nested inside a form
regardless of syntactic context.
For example, PUSH is expected to behave as if described as:
(PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place)) except that the subforms of Place
are evaluated only once, and Item is evaluated before Place."
The phase "subforms of the reference" which appears several times in
CLtL should be made more specific to be "subforms of the macro call,"
referring to the entire form that calls the generalized-variable
manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended
definition of "obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In
the form (PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place
then Item. Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Adoption Cost:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost of non-adoption:
Obvious programs may be non-portable, although it should be rare that
order of evaluation will affect actual operation.
Benefits:
The implementation and semantics of PUSH become obvious to all.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this
clarification ensures consistency across the language.
Discussion:
David Moon argues that the unstated intention of page 99
is the definition of the language, while admitting that:
"The quoted paragraphs could be taken to restrict order of evaluation
only of the subforms of (CAR (ref2)), not all of the subforms of the
PUSH form."
However, the second to last paragraph on page 99
As an example of these semantic rules, in the generalized-variable
reference (setf reference value), the value form must be evaluated
after all the subforms of the reference because the value form
appears to the right of them.
makes it clear, if it is still talking about the same semantic rules,
that in this context the phrase "generalized-variable reference" was
meant to refer to the entire macro call, not just the Place, and that
order of evaluation rules are not limited to subforms of Places. We
suggest that the next specification of Common Lisp should adopt more
consistent terminology.
No serious performance impact is expected; while some macro expansions
may appear to be more verbose, most compilers deal reasonably with the
required order of evaluation.
Problems with this version:
The rules for CHECK-TYPE, ASSERT, CTYPECASE, and CCASE need to be
stated.
Given:
(defmacro wrong-order (x y) `(get ,y ,x))
If the user writes (push a (wrong-order (frob) (baz)))
are we willing to guarantee that "the subforms of the macro call
(including but not limited to subforms of the generalized variable
reference) are evaluated exactly as many times as they appear in the
source program, and in exactly the same order as they appear in the
source program. "? No..
Note that the same issue arises for
(setf (wrong-order (frob) (baz)) 1)
so this point in no way shoots down what we originally set out to do
on the PUSH-EVALUATION-ORDER issue.
A more complicated version of wrong-order, for example, one with a loop
in it, would make it impossible to guarantee that statement. So we have
to change the statement. I think what we mean is that evaluation
of the direct subforms of the macro call and of generalized-variable
references in the macro call is ordered, but evaluation of subforms of
those subforms is determined by the recursive evaluation process as normal.
What about
(rotatef (wrong-order (frob 1) (frob 2))
(wrong-order (frob 3) (frob 4))
If the user writes an "incorrect" setf-method, e.g.,
(defsetf wrong-order (x y) (z) `(setf (get ,y ,x) ,z))
this is not an issue since CLtL p.103 says "This binding permits the
body forms to be written without regard for order-of-evaluation issues."
Of course a user could write an incorrect define-setf-method.
∂15-Nov-87 0306 CL-Cleanup-mailer Issue status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Nov 87 03:06:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 87 23:04:11 PST
Date: 14 Nov 87 23:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue status
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <871114-230411-3596@Xerox>
I'm not sure this is entirely up to date-- I don't think I've updated
the version number and date on a couple of proposals. There are a couple
of new ones in the "need volunteer" section.
Since this is not a voting meeting anyway -- we can't expect X3J13 to
vote on issues they haven't seen before, the "release" question is
really only whether we think we've sorted things out ourselves well
enough to let the rest of the community see what we're talking about.
I merged the "ready for release" and "in discussion" section because the
movement between one and the other is too frequent for me to keep track
of. The other categories are more solid.
I'm bringing a couple of copies of all of the "ready or nearly ready"
and a select few of the others.
!
Approximate status of issues under consideration by the X3J13 cleanup
subcommittee:
In discussion, some ready for release to X3J13:
- Proposal format (Version 12, 23-Oct-87)
Ready for release
- ADJUST-ARRAY-DISPLACEMENT (Version 3, 5-JUN-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
Needs revision to put back in :DISPLACED-TO option
of version 2
Not ready for release
- DO-SYMBOLS-DUPLICATES (Version 2, 29-May-87)
(Can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release
- APPEND-DOTTED (Version 3, 14-Nov-87)
(What happens to CDR of last CONS?)
Ready for release
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed at X3j13/Jun87.
Ready for release
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Ready for release
- COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
? Ready for release?
- DECLARE-MACROS (Version 2, 9-Nov-87)
(Disallow macros expanding into declarations.)
Ready for release
- DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
(Documentation string is not evaluated.)
Ready for release
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Ready for release
- FUNCTION-TYPE (Version 7, 9-Nov-87)
(Change definition of FUNCTIONP, function type ...)
Discussed at X3J13, new proposal due.
Ready for release
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Ready for release
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Ready for release
- LOAD-TIME-EVAL (Version 3, 11-Nov-87)
(New function/macro/special form for evaluation
when compiled file is loaded?)
Not ready for release
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
? Ready for release?
- PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
? Ready for release?
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
? Ready for release?
- PUSH-EVALUATION-ORDER (Version 3, 8-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not ready for release
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
Not ready for release
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
Ready for release
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
? Ready for release?
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
? Ready for release?
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
Ready for release
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(What package are *FEATURES* in?)
Ready for release
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
? Ready for release?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
Not ready for release
Tabled: Awaiting new proposal.
- ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87)
(ADJUST-ARRAY on non-adjustable arrays returns copy)
extend COPY-ARRAY instead?
- ASSOC-RASSOC-IF-KEY (Version 1, 22 Apr 87)
(Extend ASSOC-IF, etc. to allow :KEY)
Needs revision of current practice, test case, example.
(Only Symbolics is known to implement this feature)
- EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, deal with #., #, changes independently.
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction
must or even ought to work."
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
Need volunteer:
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Need volunteer to submit.
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
- DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
Is all of this mechanism necessary?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Need volunteer to submit.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
Clean up EQUAL EQUALP and friends.
- EXPORT-COORDINATION (no formal proposal)
Coordinate EXPORT and DEFxxx by adding new form.
Is this a good idea to allow?
Looking for proposal to make package manipulation lexical.
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FORMAT-COLON-UPARROW-SCOPE (not yet submitted)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion Nov 87
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer to write up.
- FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
Need volunteer to submit.
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
- INTEGER-DECODE-FLOAT-USAGE (no formal proposal)
(standardize values from INTEGER-DECODE-FLOAT)
Discussed 27 Oct on Common Lisp mail
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
- MACROLET-DESTRUCTURE
(Does MACROLET destructure its arguments?)
Discussed Common-Lisp mail Nov-87
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
re-extract from environment-arguments
CLOS notes say they need this?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- REDUCE-ARGUMENT-EXTRACTION (no proposal)
Mail on COMMON-LISP about adding a new keyword argument
to REDUCE to extract the appropriate value.
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must
be initially bound to synonym streams to *TERMINAL-IO*; demote
this to the level of an implementation suggestion. This is to
allow flexibility of implementation, for example to allow UNIX
redirection to win."
Need volunteer to submit
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
Hold: Awaiting action from another committee.
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
- IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
- IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
Approved: No further action pending.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
∂15-Nov-87 1239 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 12:39:37 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Sun 15 Nov 87 15:38:58-EST
Date: Sun 15 Nov 87 15:38:57-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Moon@SCRC-STONY-BROOK.ARPA
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19871114213919.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12350877959.8.TOURETZKY@C.CS.CMU.EDU>
Okay, here's a cleaned up description of coercion and sequences, which should
be added to the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE proposal.
1. The term "sequence" includes not only lists and vectors, but also arrays,
with the understanding that array elements are accessed in row-major order.
This guarantees that functions like LENGTH, ELT, FIND, POSITION, etc. will
behave the same way on a coerced sequence (of the same length) as on the
original sequence.
2. COERCE can convert from any type of sequence to any other. It is undefined
whether the result of a coercion shares structure with the original sequence.
3. If a sequence is coerced to a vector or array with an explicitly-specified
length N not equal to the length of the input sequence, M, then:
a) the result of the coercion must be of length exactly N, as requested
b) if N < M, the extra elements in the input sequence are ignored
c) if N > M, the initial values of the extra elements in the result
sequence are undefined
Rationale:
This extension fits naturally with the generalization of sequence functions to
operate on arrays. It changes the nature of arrays in the language by making
content more important than structure. Sequences can be converted to different
shapes, maintaining the same content, and all the sequence functions will
continue to return the same results.
Discussion:
The idea that the result of coercing an array to a vector should share
structure with the original was never part of my original proposal; it was
suggested as an alternative to the proposed extensions to the sequence
functions. I don't like it, as it forces COERCE to copy in some cases (e.g.,
string --> list) and explicitly not copy in others. Type coercion is unrelated
to the copy vs. share structure debate. Therefore we should leave it undefined
whether COERCE copies or not, except to continue the convention in CLtL that if
the input is already of the specified type, it will be returned without
copying.
-- Dave
-------
∂15-Nov-87 1853 CL-Cleanup-mailer Issue: FUNCTION-TYPE (Version 8)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 18:53:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 15 Nov 87 21:53:00-EST
Date: Sun, 15 Nov 1987 21:52 EST
Message-ID: <FAHLMAN.12350946040.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 8)
In-reply-to: Msg of 14 Nov 1987 18:59-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I still favor version 7. Maybe splitting this into two distinct
proposals makes sense, but I'm not sure that I want either part if I
can't have both, so there's also a case to be made for keeping it in one
lump.
-- Scott
∂15-Nov-87 1926 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 19:26:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 15 Nov 87 22:25:36-EST
Date: Sun, 15 Nov 1987 22:25 EST
Message-ID: <FAHLMAN.12350951963.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dave.Touretzky@C.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
In-reply-to: Msg of 15 Nov 1987 15:38-EST from Dave.Touretzky
I like the idea of extending certain sequence functions to also work on
arrays of more than one dimension. I do NOT like the idea of
considering multi-D arrays to be sequences. This seems deeply
unintuitive to me, and it is likely to have unexpected repercussions in
other parts of the language. So I am not in favor of the
proposal as modified by Touretzky.
I'm not sure what coerce should do.
-- Scott
∂15-Nov-87 2257 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 22:57:36 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Mon 16 Nov 87 01:57:11-EST
Date: Mon 16 Nov 87 01:57:08-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA,
Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <12350990498.13.TOURETZKY@C.CS.CMU.EDU>
I don't understand Fahlman's objection to calling arrays sequences. We've
considered every sequence function in CLtL, and extended them to arrays in
all the cases that made sense, which is all cases except when the result
would be a sequence that could have a diferent number of elements than
the input sequence. Given this step, we should either admit that arrays
are sequences, or else rename the sequence functions to ``sequence or array
functions.''
Let me restate the basic intuition one more time. A sequence is like a string
of beads. If you stretch it out straight you have a list or vector. If you
fold it up in various ways using COERCE or MAP, you have an n-dimensional array
which you can access with AREF, which is not a sequence function. The beads
still sit on the string in the same order, and the sequence functions still
give the same result no matter how you fold the string of beads. This property
is guaranteed by the existing commitment in CLtL to storing array elements in
row-major order.
Calling arrays sequences only affects the description of the sequence
functions; it doesn't affect array functions, string functions, etc. If Scott
overlooked this point, it might explain his intuition that the ramifications of
this change would be hard to predict or control.
Another natural consequence of my modified proposal would be to allow MAP
to return multi-dimensional arrays, since COERCE can do it.
Suppose Aij is a 3x3 array. We can apply operation F to every element of the
array, and get back a new array of the same shape, by writing
(MAP '(ARRAY * (3 3)) #'F Aij)
Note: if we just specify ARRAY for the result type, we should get back a nine
element vector instead of a 3x3 array. CLtL should be modified to indicate
that the result of MAP is a list or vector as long as the shortest input
sequence, *except* when a different length or shape is explicitly specified.
-- Dave
-------
∂16-Nov-87 0723 CL-Cleanup-mailer SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 07:23:33 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Nov 87 10:23:05-EST
Date: Mon, 16 Nov 1987 10:22 EST
Message-ID: <FAHLMAN.12351082581.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dave.Touretzky@C.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
In-reply-to: Msg of 16 Nov 1987 01:57-EST from Dave.Touretzky
I don't understand Fahlman's objection to calling arrays sequences. We've
considered every sequence function in CLtL, and extended them to arrays in
all the cases that made sense, which is all cases except when the result
would be a sequence that could have a diferent number of elements than
the input sequence. Given this step, we should either admit that arrays
are sequences, or else rename the sequence functions to ``sequence or array
functions.''
When we consider a sweeping change in the type hierarchy, it is
necessary to scan the entire manual for occurrences of "sequence" to
make sure there's not some damned little comment that will cause
trouble. Even then, there are probably some gotchas. Have you done
this?
Rearranging the type hierarchy is a big incompatible step. The
extensions to the various sequence functions were of marginal value, but
when considered as a minor extensions, the convenience probably
outweighs the cost. If people feel that changes in the type hierarchy
are a necessary part of this extension, then a whole new set of
considerations come into play. I think that the added convenience is
not sufficient to justify a change in the type hierarchy -- at least,
the case has to be considered much more carefully.
-- Scott
∂17-Nov-87 1237 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 12:37:45 PST
Received: by labrea.stanford.edu; Tue, 17 Nov 87 12:36:20 PST
Received: from kent-state.lucid.com by edsel id AA02947g; Tue, 17 Nov 87 12:31:28 PST
Received: by kent-state id AA02216g; Tue, 17 Nov 87 12:31:28 PST
Date: Tue, 17 Nov 87 12:31:28 PST
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8711172031.AA02216@kent-state.lucid.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 12 Nov 87 19:26 EST <19871113002609.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 3)
There's a problem with this SETF method for symbols. Consider the
following simplified version of SETF from p.107 of CLtL:
(DEFMACRO SETF (REFERENCE VALUE)
(MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD REFERENCE)
(DECLARE (IGNORE ACCESS-FORM))
`(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE)))
,STORE-FORM)))
This results in the following macrexpansion for (SETF X 1), using the
new SETF method for symbols:
(LET* ((G0002 X)
(G0001 1))
(SETQ X G0001))
The value of G0002 is never used. The problem is that X might be
unbound, so even just binding it to a local variable will fail. I
don't think we want to require implementations to eliminate
unnecessary bindings in SETF expansions, just to get correct
semantics. Nor should each SETF-like macro need a special case when
the location being stored is a symbol.
Unfortunately, I think special handling for symbols is necessary. If
we keep the SETF method for symbols the way it is in CLtL then we need
to make a special case for symbols in the SETF methods for GETF, LDB
and the like. If we change the SETF method as proposed here, we need
to make a special case for symbols in SETF and PSETF and any user
defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM)
from GET-SETF-METHOD.
My feeling is that we should go with the new SETF method for symbols,
but describe this problem and point out to implementors that SETF and
PSETF must handle symbols specially, effectively resorting to the old
SETF method.
∂19-Nov-87 1340 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Nov 87 13:40:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 NOV 87 13:38:44 PST
Date: 19 Nov 87 13:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
In-reply-to: Dave.Touretzky@C.CS.CMU.EDU's message of Mon, 16 Nov 87
01:57:08 EST
To: Dave.Touretzky@C.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871119-133844-9984@Xerox>
Dave:
Integers are not floating point numbers, although all of the functions
that work on floating point numbers can easily be extended to work on
integers in all the cases that make sense. Just because there is a way
of converting an array into a sequence doesn't mean that an array *is* a
sequence.
Frankly, most other programming dialects that I am aware of coerce an
array into a vector by treating
#2A((A B C) (D E F) (G H I)) coerces to #(#(A B C) #(D E F) #(G H I)),
i.e., a vector arrays. Since there are multiple reasonable views of an
array as a sequence, I'm not happy with extending COERCE: COERCE should
be left for those cases where there is a unique "natural" injection.
I believe the drift on this proposal (also in discussions in Denver) is
that we should leave the ARRAY and SEQUENCE types alone, but change the
section title of "sequence function" to talk about a set of generic
functions that work on types LIST, VECTOR, and, for some of them, ARRAY.
Post-CLOS, we might also be able to document how users can define how
these functions work for their own types, too.
This would be a gentle upward compatible change which gives us most of
what we want, without doing too much violence to our sensibilities.
∂19-Nov-87 1425 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Nov 87 14:25:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 NOV 87 14:24:35 PST
Date: 19 Nov 87 14:24 PST
From: Pedersen.pa@Xerox.COM
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
In-reply-to: Masinter.pa's message of 19 Nov 87 13:38 PST
To: Masinter.pa@Xerox.COM
cc: Dave.Touretzky@C.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871119-142435-10060@Xerox>
I agree that trying to stuff something similar to APL "reshape" and APL
"ravel" into coerce would most likely lead to confusion rather than
clarification. However, the "ravel" operation is a quite useful one --
and would be a nice complement to the proposed AREF1. "Ravel" is easily
written in terms of existing primitives, but its major value is in
abbreviating a frequent operation. E.G.
(defun ravel (array)
(typecase array
(vector array)
(array
(make-array (array-total-size array) :element-type
(array-element-type array) :displaced-to array))
(other
(error "Not an array: ~s" array)))
)
I guess it is worth insisting that the vector returned from "ravel"
share storage with the argument array.
Supposing one had "ravel", then I see no driving need for any of the
extensions outlined in "SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)".
Perhaps someone would care to enlighten me on this point. Is the
argument that distributing array coercion throughout some (but not all)
sequence functions is likely to be more efficient -- more esthetic ?
Larry's argument that the sequence functions form a paradigm that should
be extendable to include arbitrary structures is interesting, but I fail
to see how "SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)" makes this
any easier or any harder. Surely it is sufficient to make all the
sequence functions generalizable.
J.P.
∂19-Nov-87 1807 CL-Cleanup-mailer Issue: DECLARATION-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Nov 87 18:06:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 NOV 87 17:59:49 PST
Date: 19 Nov 87 17:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARATION-SCOPE
To: Pavel.pa@Xerox.COM, SMH%Franz.uucp@berkeley.edu
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871119-175949-1009@Xerox>
My notes from Denver are a little fuzzy on this issue; I think what they
mean is that you might be convinced to write up a proposal on these
issues...
I've started using our common-lisp mailing list index again, and
retrieved some of the previous mail on this subject.
----- Begin Forwarded Messages -----
Return-Path: <spar!schoen@decwrl.dec.com>
Received: from decwrl.dec.com by Xerox.COM ; 08 JUL 87 14:18:08 PDT
Received: by decwrl.dec.com (5.54.3/4.7.34)
id AA25408; Wed, 8 Jul 87 14:17:34 PDT
Received: By spar.SPAR.CAS.SLB.COM (from gyro.SPAR.CAS.SLB.COM)
id AA00706; Wed, 8 Jul 87 10:59:57 PDT
Return-Path: <schoen@gyro>
Received: By gyro.SPAR.CAS.SLB.COM
id AA09848; Wed, 8 Jul 87 10:59:31 PDT
Date: Wed, 8 Jul 87 10:59:31 PDT
From: Eric Schoen <spar!schoen@decwrl.dec.com>
Message-Id: <8707081759.AA09848@gyro.SPAR.CAS.SLB.COM>
To: masinter.pa
Subject: Common Lisp cleanup
Larry:
I think I have a submission for the cleanup committee, but I've lost
your
submission format. I'll try to provide the information you want.
Let's call this issue LET:SPECIAL-SCOPE or somesuch. Here's the crux of
the
problem. Consider a LET expression like:
(let ((a <foo>))
(declare (special a))
(bar))
I've macroexpanded this example under Franz, Lucid, TI, and Symbolics
Common
Lisps. The first three macroexpand to:
((lambda nil
(declare (special a))
((lambda (a)
(declare (special a))
(bar))
<foo>)))
The last expands to:
((lambda nil
((lambda (a)
(declare (special a))
(bar))
<foo>)))
These are exactly equivalent unless <foo> happens to be the variable a.
Under
TI, Lucid, and Franz's implementations, the interior a gets bound to the
dynamic binding of a as of the time the entire expression is entered.
Under
Symbolics, the interior a gets bound to the lexical value of a when the
expression is entered (assuming there is a lexically apparent binding of
a).
So which is the proper treatment of the special declaration? I tend to
believe Symbolics is doing it correctly, but then why do so many other
implementations do it differently?
This came up when I was trying something like the following:
(setq c (let ((a 1))
#'(lambda (function &rest args)
(let ((a a))
(declare (special a))
(apply function args)))))
(funcall c 'eval 'a)
When you do the funcall with a unbound globally, the TI, Franz, and
Lucid
implementations signal an error because a is unbound, whereas the
Symbolics
implementation returns 1. The idea in this example is to return a
closure
which captures the lexical value of a variable and makes it available
dynamically when the closure is applied. I tried simpler approaches
like
locally declaring a special within the closure, but these failed on all
implementations.
I imagine the cost of fixing all implementations to behave like the
Symbolics
implementation would be very low, since it's only a matter of changing
the
macro definition of let. The impact ought to be minor, since this is a
very
unusual situation. I also think it deserves a clarification in the
silver
book.
Eric
----- Next Message -----
Originator: @SAIL.STANFORD.EDU:Moon%STONY-BROOK.SCRC.Symbolics:COM:Xerox
Date: 18 Aug 87 14:14
From: Moon%STONY-BROOK.SCRC.Symbolics:COM:Xerox
Subject: FLET & declarations
In-Reply-to: <12327146435.14.GZ@OZ.AI.MIT.EDU>
To: GZ%OZ.AI.MIT.EDU%XX.LCS.MIT:EDU:Xerox
cc: common-lisp%SAIL.STANFORD:EDU:Xerox
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FLET & declarations
To: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12327146435.14.GZ@OZ.AI.MIT.EDU>
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 18 AUG 87 14:14:29 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18
Aug 87 13:28:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215806; Tue
18-Aug-87 16:28:17 EDT
Original-Date: Tue, 18 Aug 87 16:27 EDT
Message-ID: <870818162759.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
Date: Mon 17 Aug 87 03:57:47-EDT
From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Are 'pervasive' declarations in FLET supposed to apply to the
function bodies?
E.g.
(flet ((foo () x)) ;Is this x special?
(declare (special x))
...)
(flet ((foo () (foo) ...)) ;Does this call to (foo) return a
fixnum?
(declare (function foo () fixnum))
...)
(flet ((foo () (foo 17))) ;Is (foo 17) inline?
(declare (inline foo))
...)
CLtL does not permit DECLARE to be used in that position (see p.113).
I believe it has been proposed to change that, although I couldn't
find a copy of the proposal in my rather disorganized files. I would
argue that the paragraph in the middle of page 155 of CLtL supports
the position that when this extension is made, the pervasive
declarations
should apply to the function bodies.
Note that the FUNCTION declaration used in your middle example is not
pervasive. Since you use FLET rather than LABELS, this declaration
would not apply to the call to FOO within the body of FOO. It's a
different FOO.
The INLINE declaration is said by CLtL to be pervasive, however I
believe that to be a bug since it makes it unclear which of the two
FOOs in your example it refers to. Perhaps it refers to both.
Anyone putting together a proposal to clean up the specification of
declarations in Common Lisp ought to address the issues raised by
your question.
----- End Forwarded Messages -----
05-Jul-86 1654 Pavel.pa@Xerox.COM DECLARE SPECIAL Considered Confusing
Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 Jul 86 16:54:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 86 16:54:24 PDT
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
Subject: DECLARE SPECIAL Considered Confusing
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860705-165424-2715@Xerox>
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
Clearly, the question is whether or not the special declaration covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the reference
to ``foo'' in the call to 1+ should be special. The GLS clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth the first, second and
fourth calls to BAR are affected by the INLINE declaration, but not the
third one.''
This seems to support the view that the init-form of a binding is in a
scope outside of that of the binding itself and the body of the LET (or
FLET or ...). I prefer this view.
I would like to propose the following rule for the scope of declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of the
form and the bindings themselves. It does not affect the init-forms for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the functions
to the very functions being bound would be affected by any declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations, covering
all bindings of and references to the symbols named. Such declarations
can, of course, be countermanded by local declarations or later
proclamations.
What do people think? It would appear that some implementations already
work this way.
Pavel Curtis
Xerox AIS
!
07-Jul-86 0704 DCP@QUABBIN.SCRC.Symbolics.COM DECLARE SPECIAL
Considered Confusing
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86
07:04:50 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 16663; Mon 7-Jul-86 10:03:32 EDT
Date: Mon, 7 Jul 86 10:03 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707100308.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
What do people think? It would appear that some implementations
already
work this way.
I agree. Consider LET to be a macro that turns into LAMBDA:
(let ((foo (1+ foo)))
(declare (special foo))
foo)
=> ((lambda (foo)
(declare (special foo))
foo)
(1+ foo)) [I think this is what MacLisp actually did (does?).] The
scoping here is clear: the foo in (1+ foo) is outside the scope of the
declaration.
!
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 7 Jul 86 18:15:31
PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36962;
Mon 7-Jul-86 20:58:58 EDT
Date: Mon, 7 Jul 86 20:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I do not wish to defend the current choice of declaration-scoping rules
in Common Lisp as the best or only choice, but I do wish to clarify what
the rules are in the language as it is currently defined. It wouldn't
bother me if a future revision of the language adopted simpler rules,
provided they were truly (not just superficially) simpler.
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of
the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is incorrect here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
Clearly, the question is whether or not the special declaration
covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the
reference
to ``foo'' in the call to 1+ should be special. The GLS
clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth
the first, second and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.''
This seems to support the view that the init-form of a binding is in
a
scope outside of that of the binding itself and the body of the LET
(or
FLET or ...). I prefer this view.
The scoping of variables (and FLET functions) is different from the
scoping of pervasive declarations. There is no analogy between this
example and your previous one, because the INLINE declaration is not
attached to a binding, but the SPECIAL declaration is attached to a
binding. All that's shown by this clarification is that INLINE, just
like SPECIAL, is shadowed by an occurrence of another binding of the
same name inside its scope.
Incidentally, the bottom of p.154 says that SPECIAL is the only
declaration that falls into both classes, but I think INLINE is really
in the same category. It concerns a particular binding, but can also be
used in the absence of a binding and is pervasive for references, just
like SPECIAL.
I would like to propose the following rule for the scope of
declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of
the
form and the bindings themselves. It does not affect the init-forms
for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope
of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo
are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the
functions
to the very functions being bound would be affected by any
declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations,
covering
all bindings of and references to the symbols named. Such
declarations
can, of course, be countermanded by local declarations or later
proclamations.
What about declarations inside the body of DEFUN? With your rules I
cannot see how a declaration could ever affect the default value forms
for &optional, &key, and &aux variables. And what about declarations
inside the body of a LET*? The scoping of ones attached to variables is
fairly obvious, but what about ones not attached to variables?
We went all through this during the design of Common Lisp (I think the
discussion is available online) and the current rules resulted. Given
that we must have DECLARE at all (a point which you should not
necessarily be willing to concede), the current rules seem to work more
consistently than the alternatives that were considered.
!
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 19:45:22 PDT
Date: 7 Jul 1986 22:44-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 7-Jul-86 22:44:13.NGALL>
In-Reply-To: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Jul 86 20:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
To: Pavel.pa@Xerox.COM
Subject: DECLARE SPECIAL Considered Confusing
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
...
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is incorrect here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
I don't wish to add to the confusion here, but my reading of pg 155
agrees with VaxLisp: the above example should return 7. The outermost
LET binds a lexical var. named foo that is never referenced. The
special declaration in the inner LET affects the variable being bound by
the LET (foo) and it affects the reference to foo in the explicit body
(i.e. the last reference to foo) and the reference to foo in the
init-form in the inner LET is also special. The global value of foo is
6, and 6 + 1 = 7.
-- Nick
!
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86
20:15:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17091; Mon
7-Jul-86 23:13:40 EDT
Date: Mon, 7 Jul 86 23:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Supersedes: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860707231340.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I do not wish to defend the current choice of declaration-scoping rules
in Common Lisp as the best or only choice, but I do wish to clarify what
the rules are in the language as it is currently defined. It wouldn't
bother me if a future revision of the language adopted simpler rules,
provided they were truly (not just superficially) simpler.
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of
the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is correct here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
I apologize for the incorrect earlier version of this message that said
that VAXLISP was incorrect here. I didn't mean to add to the confusion;
it must have been a Freudian slip.
Incidentally, the incorrect result returned here by the Symbolics
implementation is a (poorly) documented incompatibility with Common Lisp
that will be fixed at some time in the future.
Clearly, the question is whether or not the special declaration
covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the
reference
to ``foo'' in the call to 1+ should be special. The GLS
clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth
the first, second and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.''
This seems to support the view that the init-form of a binding is in
a
scope outside of that of the binding itself and the body of the LET
(or
FLET or ...). I prefer this view.
The scoping of variables (and FLET functions) is different from the
scoping of pervasive declarations. There is no analogy between this
example and your previous one, because the INLINE declaration is not
attached to a binding, but the SPECIAL declaration is attached to a
binding. All that's shown by this clarification is that INLINE, just
like SPECIAL, is shadowed by an occurrence of another binding of the
same name inside its scope.
Incidentally, the bottom of p.154 says that SPECIAL is the only
declaration that falls into both classes, but I think INLINE is really
in the same category. It concerns a particular binding, but can also be
used in the absence of a binding and is pervasive for references, just
like SPECIAL.
I would like to propose the following rule for the scope of
declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of
the
form and the bindings themselves. It does not affect the init-forms
for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope
of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo
are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the
functions
to the very functions being bound would be affected by any
declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations,
covering
all bindings of and references to the symbols named. Such
declarations
can, of course, be countermanded by local declarations or later
proclamations.
What about declarations inside the body of DEFUN? With your rules I
cannot see how a declaration could ever affect the default value forms
for &optional, &key, and &aux variables. And what about declarations
inside the body of a LET*? The scoping of ones attached to variables is
fairly obvious, but what about ones not attached to variables?
We went all through this during the design of Common Lisp (I think the
discussion is available online) and the current rules resulted. Given
that we must have DECLARE at all (a point which you should not
necessarily be willing to concede), the current rules seem to work more
consistently than the alternatives that were considered.
!
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 8 Jul 86 13:54:24
PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with
NIFTP
id a002506; 7 Jul 86 19:30 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 7 Jul 86 19:27:20 -0100
Message-Id: <1672.8607071827@aiva.ed.ac.uk>
To: Common-Lisp@su-ai.arpa, DCP@scrc-quabbin.arpa, Pavel.pa@xerox.com
Subject: Re: DECLARE SPECIAL Considered Confusing
Date: Mon, 7 Jul 86 10:03 EDT
From: "David C. Plummer" <DCP@arpa.scrc-quabbin>
Subject: DECLARE SPECIAL Considered Confusing
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
What do people think? It would appear that some implementations
already
work this way.
I agree. Consider LET to be a macro that turns into LAMBDA:
(let ((foo (1+ foo)))
(declare (special foo))
foo)
=> ((lambda (foo)
(declare (special foo))
foo)
(1+ foo))
[I think this is what MacLisp actually did (does?).] The scoping
here
is clear: the foo in (1+ foo) is outside the scope of the
declaration.
If the SPECIAL declaration is to apply to the init forms, LET can be a
macro that turns into two lambdas:
(let ((foo (1+ foo))) (declare (special foo)) foo)
=> ((lambda ()
(declare (special foo))
((lambda (foo) foo) (declare (special foo)) (1+ foo))))
Some implementations do work this way.
!
Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 20:19:59
PST
Date: Mon, 10 Mar 86 19:01:24 PST
From: Jeff Barnett <jbarnett%NRTC@USC-ECL.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Re Scope and declarations
Via: Nrtc; 10 Mar 86 20:04:19
Sorry I wasn't specific enough in my last query. Therefore, I'll start
from scratch. The point that bothers me is the one made on page 155 of
CLtL. As I understand things,
(setq x 5)
(defun foo (x)
(declare (unspecial x))
(let((x (1+ x)))
(declare (special x))
x)
(print (foo 0)) outputs 6, not 1. The declare in the let form
prevades the preset expression so that the expression (1+ x) assumes the
current global binding of x outside outside the let. I can understand
that this will often be the right thing and require less writing. I
also understand that if I want to grab the lexical x that I could change
the let to start
(let((x (let()(declare (unspecial x)) (1+ x)))) which I suppose works.
(Does it?) However, if the let is produced by a macro, there is no way
to achieve this effect unless the macro can enumerate the scope of the
expression that it uses for the preset. Since the preset may be passed
into the macro, I don't think it can recover in any graceful way unless
you think that
(let((g exp))
(let((x g))
(declare (special x)) etc)) where g is a gensym, is graceful.
Another problem with declares prevading presets is that the following
are not equivelent:
(let((v1 e1) (v2 e2)) (declare (something-about v1 v2)) body...)
((lambda(v1 v2) (declare (something-about v1 v2)) body...) e1 e2)
Further, I think the proposed standard is incompatible with virtually
all other LISP implementations. I don't think that this is a good idea
for CL. Any comments and clarifications as to all of this would be
appreciated.
Jeff
!
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 May 85
16:33:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230444; Sun 5-May-85
19:31:32-EDT
Date: Sun, 5 May 85 19:30 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: mysterious declarations off in left field
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12108630198.BABYL@CMU-CS-C.ARPA>
Message-ID: <850505193039.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 5 May 1985 14:12 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Don't packages offer an alternative way of scoping declarations?
Sure, but packages normally function at a very large grain size.
Sometimes you want to add something to a package without having to
scan
the whole package definition to ensure that some fool has not
declared X
to be a quadruple-float.
Or SPECIAL! I've already had problems in Macsyma source code with
closures that didn't "close" because someone decided STRING should be a
special variable. I guess you can imagine how that would be a pretty
high-probability variable name and a poor choice of special name ...
Consider too that names like LIST, STRING, etc. are not likely to be
private -- nearly everyone is going to inherit them from GLOBAL -- so
the first time anyone in any "package" declares one of them to be
special, it screws everyone else who tries to do compilations in that
environment.
If I bind a lexical X, that's my X and I'm not interested in anyone
else's views about what type X's in general should be.
Indeed.
Actually, I wonder if we shouldn't have said that type proclamations
should pertain only to special variables. eg,
(PROCLAIM '(TYPE FLOAT TOLERANCE))
might have only applied to special occurrences of TOLERANCE. This would
mean that people using variables lexically in other modules would be far
less likely to find irrelevant declarations affecting them...
In cases where people wanted to make assertions about lexical variables,
they should perhaps have to scope such declarations lexically.
Although obviously such a change is somewhat incompatible, we might
consider it (or something like it) for the next round of revisions. (An
alternate approach which would achieve the same end would be to
introduce a new declaration operator which had the property of applying
only to special
occurrences so that people could choose which style they wanted.)
Of course this doesn't solve the problem I alluded to earlier of having
people declare things special behind my back...
!
Received: from MIT-ML by SU-AI with TCP/SMTP; 20 Dec 83 12:52:05 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 20-Dec-83
15:53:04-EST
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
I have an alternate proposal for declarations. It is mainly intended as
an easier-to-understand way of explaining things that gives the same
semantics, but it also resolves the inconsistencies in the manual (Mary
Poppins and Excelsior editions) in a way that is probably inconsistent
with the intent of the manual, but is more consistent with the Laser
edition and with the practice in previous lisps such as Maclisp and Lisp
Machine Lisp. I realize it is rather late for this kind of thing, but
given that the manual is inconsistent with itself and that some people
were surprised by the change from last year's version of the language,
maybe we can reconsider. In any case this way of explaining things seems
to be easier to understand.
The basic problem is the SPECIAL declaration, which falls into both
categories of declarations: it both concerns the binding of variables
and is pervasive. This is not well explained in the manual and seems to
be a great source of confusion. I propose to flush the idea that
SPECIAL declarations are pervasive. Read on before judging.
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
None of this is new. What about SPECIAL declarations? I propose that
SPECIAL declarations be put entirely into the first category, in the
following way:
When a declaration, (SPECIAL X), is attached to a form (or
lambda-expression) it creates a -lexical- binding of the name X in that
form. Unlike all other bindings, this binding does not associate a
value with the name X. Instead, it associates a "special" marker with
the name. Any text that is in the lexical scope of this binding, and
uses the variable X, refers to the dynamic binding of X, because it sees
the "special" marker. The scope of a SPECIAL declaration is precisely
defined by the scope of this binding. Note how close this definition is
to the way that some interpreters actually work internally.
In addition to creating this lexical binding, a (SPECIAL X) declaration
also changes the meaning of a binding, if there is one, of the variable
X in the form to which the declaration is attached; it causes that
binding to be a dynamic binding rather than a lexical binding. This
applies only to the form to which the declaration is directly attached,
not to any subforms of it. (This is not new.)
The declaration-allowing forms FLET, LABELS, LOCALLY, and MACROLET do
not normally create bindings of variable names (only function names), so
we have a slight exception, permitting SPECIAL declarations inside them
to create such bindings.
We now understand completely how the SPECIAL declaration works in LET.
Three examples:
(defun foo (x)
(let ((x x))
(declare (special x))
(bar x))) Reading from left to right, there are five occurrences of
x. The declaration causes the second and fifth to refer to a dynamic
variable, while the first and third refer to a lexical variable. (The
fourth occurrence is the one in the declaration itself). The third
occurrence of x does not refer to the dynamic variable, because it is
not in the scope of the lexical binding of the name x created by the
special declaration, because of the way LET defines scoping in its
subforms.
(defun foo ()
(declare (special x))
(bar x)) The declaration causes the second occurrence of x to refer,
freely, to a dynamic variable, because this x is inside the lexical
scope of a binding of the name x attached to the defun.
(defun foo ()
(let ((x (quux)))
(mumble x)
(locally
(declare (special x))
(bar x)))) Here the first and second occurrences of x refer to a
lexical variable, while the fourth refers to a dynamic variable. The
binding of the name x in the LOCALLY shadows the binding of the name x
in the LET.
There remains the issue of how sequential binding forms such as LET* and
DEFUN should work. (DEFUN uses sequential binding with respect to
initial value forms for &optional, &key, and &aux variables). When a
SPECIAL declaration creates a lexical binding of a name in such a form,
at what position in the sequence of bindings should it be inserted?
This makes a difference because it affects whether the scope of the
declaration includes or excludes the initial value forms. Clearly if
the form includes a (dynamic) binding of the name being declared, then
the (lexical) binding created by the declaration should be inserted at
that point. Otherwise we can either insert the declaration's binding at
the beginning of the sequence of bindings, giving it the largest
possible scope, or at the end, giving it the smallest possible scope. I
suggest putting it at the beginning, because that is what people seem to
expect with DEFUN (see the example at the bottom of page 126.) Two
examples:
(defun foo (x)
(let* ((x (bar x))
(y (quu x)))
(declare (special x))
...)) The first and third occurrences of x refer to a lexical
variable, while the second and fourth refer to a dynamic variable. (bar
x) is outside the scope of the special declaration while (quu x) is
inside its scope.
(defun foo (x)
(let* ((w (bar x))
(y (quu x)))
(declare (special x))
...)) The first occurrence of x refers to a lexical variable, while
the second and third refer, freely, to a dynamic variable. Both (bar x)
and (quu x) are inside the scope of the special declaration. If let had
been used instead of let*, neither of them would be inside the scope of
the declaration.
For explanatory purposes, the above two examples could be written on
paper as
(defun foo (x)
(let* ((x (bar x))
(x @I[special])
(y (quu x)))
(declare (special x))
...))
(defun foo (x)
(let* ((x @I[special])
(w (bar x))
(y (quu x)))
(declare (special x))
...))
∂19-Nov-87 2102 CL-Cleanup-mailer Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 87 21:02:27 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Fri 20 Nov 87 00:01:54-EST
Date: Fri 20 Nov 87 00:01:52-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Masinter.pa@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871119-133844-9984@Xerox>
Message-ID: <12352018090.16.TOURETZKY@C.CS.CMU.EDU>
Okay, I concede that the array/sequence issue isn't as clear cut as I made it
out to be. I will be happy to go with Version 4 as stated, except we should
cut out any mention of COERCE.
In reply to Petersen, I think the proposal to use explicit raveling in place of
extending the sequence functions as described in Version 4 is unacceptable on
aesthetic grounds. It makes for really ugly code. It treats vectors
differently than arrays (since only arrays need to be raveled), which is
awkward. It misses the fact that sequence functions like FILL and COUNT are
already generalized to arrays in non-Lisp contexts; in English we use the
generalized forms all the time, e.g., "count the number of 1's in this matrix."
I look forward to the day when I can say (FILL MY-MATRIX 0.0) and have Lisp
do the right thing.
-- Dave
-------
∂20-Nov-87 1114 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 11:14:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 11:13:31 PST
Date: 20 Nov 87 11:13 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: CONSTANT-SIDE-EFFECTS
To: CL-CLEANUP@Sail.stanford.edu
Message-ID: <871120-111331-1723@Xerox>
This issue is mentioned by Rob's Compiler Proposal, although subsequent
mail on that topic shows that the wording is tricky.
Since I had it on my list of issues, I'll keep it there, mark it as
Pending Compiler Proposal. If there isn't a compiler proposal by the
next X3J13 meeting from the compiler subcommittee, we may have to take
it on ourselves.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79Date: Wed,
25 Feb 87 23:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rob's Compiler Cleanup Proposal
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12281173600.BABYL@C.CS.CMU.EDU>
Message-ID: <870225230554.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
. . .
"It is an error to destructively modify any part of a Lisp data
structure that
has been promoted to a program."
Does this mean that it is illegal to do things like
(DEFVAR *FOO* '(1 2 3))
(SETF (CDR *FOO*) NIL)
(SETQ A '(1 3 4))
(SETF (SECOND A) 2)
even when interacting with the read-eval-print loop? This needs to be
more clearly defined. Also, if users have to copy any quoted data
structures
they plan to modify, Common Lisp's lack of a really general copying
primitive
(for good reasons, defining the semantics is hard) becomes more glaring.
RAM:
I would say that it would be legal for an implementation to bum out
when you do this, but users might reasonably consider this to be
unreasonable behavior. There currently is a note about it being
unreasonable for the system do strange things to constants typed in at
top level. Perhaps this should be expanded on in a discussion of
top-level philosophy, but I don't think this is really very important
for the standard, since people will be porting programs rather than
transcripts of top-level sessions.
MOON:
"When the system promotes a data structure to a program, it may
non-destructively replace any part of the program with any
structurally
equivalent data structure that is known to be unmodifiable."
How can you "non-destructively replace" something? I think I know
what this means but it should be stated more clearly. And if there are
good reasons to forbid destructive replacement they should be clearly
stated too.
RAM:
Well, I think it would pretty strange for EVAL to destructively modify
its argument. I guess "non-destructive replace any part" means that
the system is free to do something equivalent to building a new
structurally equivalent form that may contain old structures as parts.
From Issue file:
(*) 56, 68 Clarify that using DEFCONSTANT to redefine any constant
described in the Common Lisp specification is an error. Clarify that if
the user defines a constant, compiles code that refers to that constant,
and then redefines the constant, then behavior of the compiled code may
be unpredictable. (Perhaps it ``is an error'' to execute such code.)
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 21:11:22
PDT
Received: by su-navajo.arpa with TCP; Tue, 3 Sep 85 21:10:23 pdt
Received: by edsel.uucp (2.0/SMI-2.0)
id AA16018; Tue, 3 Sep 85 20:07:30 pdt
Date: Tue, 3 Sep 85 20:07:30 pdt
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8509040307.AA16018@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Modifying constants in programs
Here is a paragraph from CLtL which has some bearing on the discussion
of modifying constants in code:
''An additional problem with EQ is that the implementation is permitted
to "collapse" constants (or portions thereof) appearing in code to be
compiled if they are EQUAL. An object is considered to be a constant in
code to be compiled if it is a self-evaluating form or is contained in a
QUOTE form. This is why (EQ "Foo" "Foo") might be true or false; in
interpreted code it would normally be false, because reading in the form
(EQ "Foo" "Foo") would construct distinct strings for the two arguments
to EQ, but the compiler might choose to use the same identical string or
two distinct copies as the two arguments in the call to EQ. Similarly,
(EQ '(A . B) '(A . B)) might be true or false, depending on whether the
constant conses appearing in the QUOTE forms were collapsed by the
compiler. However, (EQ (CONS 'A 'B) (CONS 'A 'B)) is always false,
because every distinct call to the CONS function necessarily produces a
new and distinct cons.''
This implies that it is illegal to modify a constant in compiled code,
since the compiler is licensed to share all or part of that constant
with other compiled code.
For the particular example of COMPUTE-ONCE, it is not necessary to use a
special variable to hold the computed value. A lexical variable will
suffice. The scope of the lexical variable must include the entire
function in which it is referenced. This is similar to an OWN variable
in Algol 60.
!
∂20-Nov-87 1148 CL-Cleanup-mailer meeting report, Issue status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 11:48:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 11:47:41 PST
Date: 20 Nov 87 11:47 PST
From: Masinter.pa@Xerox.COM
Subject: meeting report, Issue status
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871120-114741-1769@Xerox>
A large number of the open issues were discussed and resolution made. I
am going to try to send out mail on all of the issues for which I have
notes. We got people to at least say they would volunteer on a large
number of the "Need Volunteer" list.
My goal is to try to get all of the issues under consideration resolved
and voted on by the June meeting. This means a considerably more
aggressive schedule than we've operated on so far. The goal for X3J13 is
to have a complete draft of a standard within one year, including CLOS,
Signal/Error, compilation, and cleanup.
We all know that things can go wrong and that schedules can slip, but
this seems doable enough that I'm willing to push for it.
∂20-Nov-87 1149 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 11:49:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 11:49:09 PST
Date: 20 Nov 87 11:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: CONSTANT-SIDE-EFFECTS
To: cl-cleanup@sail.stanford.edu
Message-ID: <871120-114909-1773@Xerox>
Some additional puzzles:
- - - - - -
(defvar a (list 1 2 3 4))
(defconstant b a)
(setf (car a) 4)
- - - - - -
(nconc `(,x 5 6 7) y)
∂20-Nov-87 1220 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 12:20:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 12:19:18 PST
Date: 20 Nov 87 12:19 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: NO
cc: vax135!lcuxle!elia@ucbvax.Berkeley.edu,
DCP@QUABBIN.SCRC.Symbolics.COM, Masinter.pa@Xerox.COM
Message-ID: <871120-121918-1812@Xerox>
As penance for having dropped this simple issue, I offer you version 2.
I moved some of the discussion around, added a (not very good) example.
This issue sports the new "Cost to implementors" and "Cost to users" section
headings.
A better or more compelling example is welcome.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Version 2 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT
do not mention a :KEY option, although ASSOC and RASSOC have one.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords
for other -IF and -IF-NOT functions. The function, as with the :KEY argument
for ASSOC and RASSOC, are applied to the CAR of the pair in the association
list.
Documentation impact:
A better description of the intent might be to say that the car /contains/
the key of the association, and by default the car /is/ the key of the
association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one
with zero version.
Rationale:
This is an inconsistency in the language which is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions.
Franz and Xerox follow the book. TI Explorer doe not allow :KEY at all.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in
their calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the
:TEST and :TEST-NOT keywords, but allow :KEY. For example, consider
the family of MEMBER, MEMBER-IF, and MEMBER-IF-NOT.
Although this introduces additional mechanism, it does so in a way that
probably makes it easier to think about which functions do what, so it
would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an
oversight.
The cleanup committee supports this change/clarification.
∂20-Nov-87 1235 CL-Cleanup-mailer Proposal Format (Version 13)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 12:35:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 12:34:44 PST
Date: 20 Nov 87 12:34 PST
From: Masinter.pa@Xerox.COM
Subject: Proposal Format (Version 13)
to: cl-cleanup@Sail.stanford.edu
CC: MASINTER.pa@Xerox.COM
line-fold: no
Message-ID: <871120-123444-1850@Xerox>
This is the proposal format with some changes to section titles, a bit
of reorganization (to put the Costs together and the Benefits together),
and some minor changes to the rules: I described what I thought was an
Example vs a Test Case, etc.
!
Format for proposals to the cleanup committee (Version 13)
November 20, 1987
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable
symbol in the Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being
discussed, and other references, including other
related issues.<<
Category: >>One or more of:
CLARIFICATION -- proposal to resolve an ambiguity or case
of under-specified situation in CLtL, where this
ambiguity interferes with portability of code.
CHANGE -- proposal for an incompatible change.
ADDITION -- proposal for a compatible extension<<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL. If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details. Avoid arguing for the proposal here, just describe
it.<<
Test Cases/Examples:
>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text.
Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if you need.)
<<
Rationale:
>> A one or two sentence summary of the arguments that follow. <<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<
Cost to Implementors:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost to Users:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<
∂20-Nov-87 1311 CL-Cleanup-mailer Re: Issue: ASSOC-RASSOC-IF-KEY (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 13:11:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 13:10:30 PST
Date: Fri, 20 Nov 87 13:06:07 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: ASSOC-RASSOC-IF-KEY (Version 2)
In-reply-to: <871120-121918-1812@Xerox>
To: CL-Cleanup@SAIL.STANFORD.EDU,
vax135!lcuxle!elia@ucbvax.Berkeley.edu, DCP@QUABBIN.SCRC.Symbolics.COM
Message-ID: <871120-131030-1901@Xerox>
I favor this.
Pavel
∂20-Nov-87 1331 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 87 13:27:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 87 13:20:00 PST
Date: 20 Nov 87 13:19 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: NO
Supercedes: <871120-121918-1812@Xerox>
cc: vax135!lcuxle!elia@ucbvax.Berkeley.edu,
DCP@QUABBIN.SCRC.Symbolics.COM, Masinter.pa@Xerox.COM
Message-ID: <871120-132000-1924@Xerox>
Version 2 had a mistake. The :KEY is applied to the CDR in RASSOC.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT
do not mention a :KEY option, although ASSOC and RASSOC have one.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords
for other -IF and -IF-NOT functions. The function, as with the :KEY argument
for ASSOC and RASSOC, are applied to the CAR of the pair in the association
list for ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/
the key of the association, and by default the car /is/ the key of the
association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one
with zero version.
Rationale:
This is an inconsistency in the language which is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions.
Franz and Xerox follow the book. TI Explorer doe not allow :KEY at all.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in
their calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the
:TEST and :TEST-NOT keywords, but allow :KEY. For example, consider
the family of MEMBER, MEMBER-IF, and MEMBER-IF-NOT.
Although this introduces additional mechanism, it does so in a way that
probably makes it easier to think about which functions do what, so it
would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an
oversight.
The cleanup committee supports this change/clarification.
∂23-Nov-87 1205 CL-Cleanup-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:05:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 12:01:02 PST
Date: 23 Nov 87 12:00 PST
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Message-ID: <871123-120102-2456@Xerox>
We last discussed this issue in June. If anyone wants to review the
mail, let me know.
This version attempts to clarify that omitting :DISPLACED-TO is the same
as :DISPLACED-TO NIL (rather than defaulting to the original
:DISPLACED-TO target, as I had assumed in a previous version.)
Frankly, I've a growing enthusiasm for considering *removing* adjustable
arrays from the standard given the amount of hair involved. Maybe its
because I've never been able to imagine a use....
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (Steele p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Version 4 by Masinter, 23-Nov-87
Problem Description:
The interaction of ADJUST-ARRAY and displaced arrays is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Interaction of adjusting and displacement:
Suppose we are adjusting array A, which is perhaps displaced to B before
the ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :INITIAL-ELEMENT. The use of :INITIAL-CONTENTS
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before the call, and is displaced to C after the
call. (B and C may be the same.) As in case (2), the contents of B do
not appear in A afterward (unless such contents also happen to be in C).
If :DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it
defaults to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :INITIAL-ELEMENT. However, the use of
:INITIAL-CONTENTS causes all old contents to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z,
and array Y is altered by ADJUST-ARRAY, array X must now refer to the
adjusted contents of Y. This means that an implementation may not
collapse the chain to make X refer to Z directly and forget that the
chain of reference passes through array Y. (Cacheing techniques are of
course permitted, as long as they preserve the semantics specified here
and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent
to specifying :DISPLACED-TO NIL; in either case, the array is not
displaced after the call and case (1) or (4) hold.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here, although
they differ in some detail. For example, Symbolics Common Lisp behaves
as indicated except for case (4); in that case, it never copies the
contents of B, and all elements are taken from the :INITIAL-ELEMENT.
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
The cleanup committee supports this clarification.
Some consideration was given to adding DISPLACED-ARRAY-P or
ARRAY-DISPLACED-TO and ARRAY-DISPLACED-INDEX-OFFSET which would allow
access to information as to whether an array was or was not displaced.
However, these are not part of the current proposal.
A similar issue arises with ADJUST-ARRAY and fill pointers, and will be
the subject of a separate issue.
∂23-Nov-87 1227 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:27:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 12:25:35 PST
Date: 23 Nov 87 12:25 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 4)
Message-ID: <871123-122535-2508@Xerox>
At X3J13, Bekerly (sp?) expressed some concern that APPEND might in some
circumstances return a non-list. I quoted more extensively from CLtL so
that it would be more obvious that this was the only reasonable
clarification that was compatible with the current description.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue
of what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be
any LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is
not a list, the behavior when any of the other arguments are not lists.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given
to APPEND or NCONC is discarded (whether NIL or not) when preparing the
list to be returned.
In the degenerate case where there is no last cons (i.e., the argument
is NIL) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations
involving dotted lists. As such, deciding which to use is not just a
stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined
across implementations. This proposal upholds the apparent status quo in
a number of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND or NCONC
incompatibly, the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow
things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and
NCONC can therefore produce dotted lists, some readers may have
(incorrectly) assumed that APPEND and NCONC can reliably deal in general
with dotted lists, something that doesn't appear to be guaranteed by a
strict reading. The proposed extension would happen to legitimize such
assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list
may feel differently than those who view lists as a special kind of
dotted list.
Discussion:
The cleanup committee supports this proposal.
∂23-Nov-87 1227 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:27:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 12:26:50 PST
Date: 23 Nov 87 12:26 PST
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 4)
Message-ID: <871123-122650-2514@Xerox>
<Supercedes previous message; the version number wasn't in the proposal
although in the Subject line.>
At X3J13, Bekerly (sp?) expressed some concern that APPEND might in some
circumstances return a non-list. I quoted more extensively from CLtL so
that it would be more obvious that this was the only reasonable
clarification that was compatible with the current description.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue
of what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be
any LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is
not a list, the behavior when any of the other arguments are not lists.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given
to APPEND or NCONC is discarded (whether NIL or not) when preparing the
list to be returned.
In the degenerate case where there is no last cons (i.e., the argument
is NIL) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations
involving dotted lists. As such, deciding which to use is not just a
stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined
across implementations. This proposal upholds the apparent status quo in
a number of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND or NCONC
incompatibly, the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow
things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and
NCONC can therefore produce dotted lists, some readers may have
(incorrectly) assumed that APPEND and NCONC can reliably deal in general
with dotted lists, something that doesn't appear to be guaranteed by a
strict reading. The proposed extension would happen to legitimize such
assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list
may feel differently than those who view lists as a special kind of
dotted list.
Discussion:
The cleanup committee supports this proposal.
∂23-Nov-87 1245 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:45:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 12:42:11 PST
Date: 23 Nov 87 12:42 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <871123-124211-2551@Xerox>
I should know better than to take a second-hand report on current practice.
I removed the mention of TI. In response to a private message, I changed
a which to that (or was it a that to a which). Whichever thatever was,
I fixed it, lest this turn into another which-hunt.
Given the amount of mail on the Common Lisp mailing list, I felt justified
in saying that this was often reported as an inconsistency... at least it
makes it sound like a problem.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT
do not mention a :KEY option, although ASSOC and RASSOC have one.
This is often reported as an inconsistency in Common Lisp.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords
for other -IF and -IF-NOT functions. The function, as with the :KEY argument
for ASSOC and RASSOC, are applied to the CAR of the pair in the association
list for ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/
the key of the association, and by default the car /is/ the key of the
association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one
with zero version.
Rationale:
This is an inconsistency in the language that is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions.
Others follow the book and allow :KEY only for ASSOC.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in
their calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the
:TEST and :TEST-NOT keywords, but allow :KEY. For example, consider
the family of MEMBER, MEMBER-IF, and MEMBER-IF-NOT.
Although this introduces additional mechanism, it does so in a way that
probably makes it easier to think about which functions do what, so it
would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an
oversight.
The cleanup committee supports this proposal.
∂23-Nov-87 1300 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 12:59:53 PST
Received: from Salvador.ms by ArpaGateway.ms ; 23 NOV 87 12:52:02 PST
Date: 23 Nov 87 12:51 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <871123-125202-2581@Xerox>
Version 3 had an incomplete sentence under "cost of not adopting this
change". I removed it, and put the negation in the Benefits section.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Version 4 by Masinter 23-Nov-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say
whether *BREAK-ON-WARNINGS* affects warnings output by the compiler. If
this is to be allowed, it should be an explicitly expressed part of the
contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these
functions are required to break on warnings if *BREAK-ON-WARNINGS* is
true (just as if it calls WARN).
Note: User interface commands provided by particular vendor
implementations which implicitly call COMPILE or COMPILE-FILE could bind
*BREAK-ON-WARNINGS* back to NIL if they felt it important to not break
for some reason relating to cultural compatibility. This would not
interfere with the proposed new semantics for the functions COMPILE and
COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when
warnings occur. If the compiler is permitted to warn (separate ballot
item), the effect of this variable on compiler warnings should be nailed
down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism
might have to be edited, but it would not be a major change.
Conversion Cost:
Probably little or no user code would be affected by this change.
Benefits:
This would make the language definition more consistent by making it
less subject to special cases. Portable programs can be assured of
consistent behavior when dealing with the compiler.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather
than the language.
We considered but rejected the notion of a separate
*COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be
replaced in its entirity by a more structured signal/handler structure,
making this proposal moot.
∂23-Nov-87 1306 CL-Cleanup-mailer Re: DECLARE-MACROS (Version 2) Volunteer wanted.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 13:06:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 13:03:30 PST
Date: 23 Nov 87 13:03 PST
From: Masinter.pa@Xerox.COM
Subject: Re: DECLARE-MACROS (Version 2) Volunteer wanted.
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871123-130330-2620@Xerox>
At X3J13, the discussion of this issue led me to believe that we should
do a more extensive job of surveying current uses of macros that expand
into declare and the alternative syntactic forms that we might provide.
For example, several folks spoke of providing a single macro, e.g.,
(inner), that expanded into a (declare (optimize ...)) for those "inner"
routines that they wanted to turn type checking off locally.
(defun foo (a b c) (inner) ...)
(defun frob (a b c) ...)
(defun another (args) (inner) ...)
I suggested another alternative which was to
(defmacro inner (&rest body) `(locally (Declare (optimize ...)) ,@body))
and then wrapping the entire DEFUN, e.g.,
(inner
(defun foo (a b c) ...)
)
I'd appreciate some help from those who surveyed their user community to
expand the alternatives. (Probably the simplest way to organize this is
to put in the "Cost to users" section that alternatives exist, and then
to elaborate them in the Discussion section.)
- - - -- -
Second, there was some enough mention of the destructive-macro-caching
example that we should probably put it back in as another justification
for this proposal. Also, the fact that a straightforward expansion of
(my-let (var1) (my-let (var2) (my-let (var3) ...)))
might result in 2↑n macro expansions of the innermost form.
∂23-Nov-87 1319 CL-Cleanup-mailer Re: DECLARE-MACROS (Version 2) Volunteer wanted.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 13:19:11 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287007; Mon 23-Nov-87 16:18:41 EST
Date: Mon, 23 Nov 87 16:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: DECLARE-MACROS (Version 2) Volunteer wanted.
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-130330-2620@Xerox>
Message-ID: <871123161832.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm not convinced that the user impact is a big deal. There are a number
of useful workarounds which this proposal could (and apparently should)
suggest which will tend to nullify the effect on users.
I plan to submit a revised copy of DECLARE-MACROS that will factor in the
feedback we got from Gold Hill and Franz, and then we can work from there.
(Larry: I'll try to do this in the near future. Bug me if I don't seem to
have gotten to it by, say, next week.)
∂23-Nov-87 1326 CL-Cleanup-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 13:26:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 13:22:57 PST
Date: 23 Nov 87 13:22 PST
From: Masinter.pa@Xerox.COM
TO: CL-CLEANUP@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
Message-ID: <871123-132257-2668@Xerox>
The rationale is extended to point out that no other documentation
string positions are evaluated for any of the other defining forms. I
added an example. I added to the Benefit section about programming
environment tools. (It seems reasonable, for example, to be able to
extract the doc string from the defining form at "code-walk" time.)
These changes are in response to more than one "why not?" query at
X3J13. Opinions?
!
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
23-Nov-87, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether the documentation part of DEFVAR,
DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and
DEFCONSTANT special forms is not evaluated. That is, it must be a
literal string, not a form which evaluates to a string.
Examples:
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation
string") ; OK
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE)
GENERIC-DOCUMENTATION-STRING) ; would be an error
Rationale:
To ensure portability, implementations must agree on whether or not this
position is evaluated. Specifying that the position is unevaluated is
the conservative thing to suggest, and consistent with the (unevaluated)
documentation strings in DEFUN, DEFSTRUCT.
Current Practice:
Some implementations evaluate this position. Others do not.
Cost to implementors:
Implementations that did not already check might usefully add a check in
the macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert
that the DOCUMENTATION, if supplied, was a string. The change is likely
trivial.
Conversion Cost:
Code which uses other than a literal string is not portable, so no
portable programs will be broken. Some non-portable programs which rely
on a particular vendor's interpretation would have to be rewritten.
Automatic tools to detect most offending cases could trivially be
constructed. (We know of no current uses.)
Benefits:
Code portability would be improved. Some programming environment tools
might assume that documentation strings were determinable without
evaluation.
Aesthetics:
Slight improvement; this implies consistent treatment for documentation
strings in all defining forms.
Discussion:
We think this is a good idea.
----- End Forwarded Messages -----
∂23-Nov-87 1403 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 14:03:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 14:02:49 PST
Date: 23 Nov 87 14:02 PST
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
CC: Masinter.pa@Xerox.COM
Message-ID: <871123-140249-2744@Xerox>
There is no apparent consensus on this issue. Various folks
said they would like a version that had keywords and didn't like
allowing duplicates, but in lieu of a consensus for change, we're
left with the status quo.
This version removes the ADD-KEYWORDS alternative proposal, and
adds to the discussion.
I removed an awkward phrase which read
"Users who have been assuming [no duplicates]...
will have to be modified."
although perhaps that is what we mean.
!
Issue: DO-SYMBOLS-DUPLICATES
References: DO-SYMBOLS, CLtL p.187
Category: Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87
Problem Description:
CLtL specifies that DO-SYMBOLS executes the body once for each symbol
accessible in the package. It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed). It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.
Example:
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X))
;; this may print ASYM once or twice.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates. For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications. Users who really
want the duplicates to be removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Cost to implementors:
None. Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.
Cost to users:
Code written assuming that DO-SYMBOLS eliminates duplications
will have to be modified. (Such code was not truly portable.)
Benefits:
Clarification of a situation that is currently ambiguous.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a
clear case of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.
The need for do-symbols to be efficient is questionable, however; for
many applications (e.g., global package manipulation), duplicate values
would create havoc.
For some implementations, the performance penalty would be well over
a factor of two.
Several proposals were considered for adding keyword arguments
to DO-SYMBOLS which might specify :ALLOW-DUPLICATES, adding keywords
and eliminating DO-EXTERNAL-SYMBOLS, etc., but no clear consensus
was reached for making additions.
This version is the closest to the status quo.
∂23-Nov-87 1442 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE (Version 8)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 14:42:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 14:41:29 PST
Date: 23 Nov 87 14:41 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 8)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sat, 14 Nov 87 18:59 EST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871123-144129-2814@Xerox>
I believe this issue may well come to a vote -- i.e., not decided by
consensus. There are fairly strong feelings on both sides of the
coercion issue.
I don't think it is ready for a vote until it is clear that the folks
voting understand the issue and its ramification. There were enough
questions and incorrect assumptions at X3J13 that I believe we need to
work harder to explain the issues.
There were several folks who believed that removing coercion removed
late binding in several circumstances.
One example:
(mapcar 'frob my-list)
if, during the course of execution of frob, one should hit a breakpoint
and redefine frob, would subsequent iterations get the new definition?
More examples of the coercion are called for, I think.
Frankly, I didn't detect any large amount of enthusiasm for introducing
a new name PROCEDURE in order to avoid stepping on the current
definition of FUNCTION. Do any of you have any additional comments on
this, one way or another?
Someone afterward said that Kent had put up an example of why coercing
was important ... this seems important to add to the proposal.
∂23-Nov-87 1443 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 14:43:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 287159; 23 Nov 87 17:42:48 EST
Date: Mon, 23 Nov 87 17:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-140249-2744@Xerox>
Message-ID: <19871123224244.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Nov 87 14:02 PST
From: Masinter.pa@Xerox.COM
I removed an awkward phrase which read
"Users who have been assuming [no duplicates]...
will have to be modified."
although perhaps that is what we mean.
Perhaps "Users who" was a typo for "Uses which".
∂23-Nov-87 1602 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 16:02:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 15:08:23 PST
Date: 23 Nov 87 15:08 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION
To: cl-cleanup@sail.stanford.edu
Message-ID: <871123-150823-2868@Xerox>
The mail I sent to Dabrowski@ICST-ECF.ARPA on this issue was returned as
undeliverable.
I think perhaps this issue deserves a writeup (merging it with
SPECIAL-FORM-SHADOW).
There was one proposal mentioned to bring into the standard some
facilities for declaring that certain symbols were "locked" and not
subject to redefinition (local or global).
My belief is that without a new macro expansion mechanism, there is no
way that we can ensure portability without severe restrictions on
implementations. Given:
(flet ((open ))
(with-open-file ...))
will the expansion of with-open-file use OPEN or SI::OPEN?
There is a small interaction with CLOS in the sense that adding new
methods for a generic function "redefines" the generic function in some
(explicitly allowed) ways.
On the other hand, this may be beyond the scope of the cleanup
committee.
I will leave this issue marked as Need Volunteer unless I hear
otherwise.
∂23-Nov-87 1740 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 87 17:40:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 87 17:40:07 PST
Date: 23 Nov 87 17:39 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 4)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <871123-174007-3050@Xerox>
I added a reference (Wilensky) and cleaned up the discussion and
mentioned some of the other points that came up in the discussion but
haven't been addressed separately. I suppose I need to assign issue
names for extending COERCE to PATHNAME and requiring STREAM to be
disjoint, although I'm not sure if we want to generalize those to
extending COERCE in lots of ways, and requiring more than STREAM to be
disjoint.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426)
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Category: CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically,
PATHNAME, TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST,
PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE,
PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING, DIRECTORY-NAMESTRING,
HOST-NAMESTRING, ENOUGH-NAMESTRING are changed by this proposal to not
allow symbols for their pathname argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their
file or filename argument, and that DIRECTORY does not allow a symbol
for its pathname argument. This is implied by the respective
descriptions of those functions in CLtL, but as explicitly stated.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in
MacLisp (which did not have strings) and causes much error-prone
behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since
this appears to be an "is an error" rather than "signals an error"
situation, no implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings. For example,
some users are used to typing interactively (LOAD 'FOO) to mean (LOAD
"FOO"). This is not explicitly allowed in CLtL, so such behavior has not
been portable. However, such use is probably widespread among users of
implementations that allow it (e.g., Common LISPCraft gives this form in
an example.)
Benefits:
Pathname functions will be more consistent. In implementations that
check the type of this argument, program error checking will be
improved. In dealing with case-sensitive file systems, users won't do
(load 'foo) and wonder why file "FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is
erroneously substituted for a pathname, perhaps because GETHASH or ASSOC
didn't find a table entry that was expected to exist and returned
-false-. In systems that accept symbols as pathnames, this causes a
reference to a file named "NIL" on some perhaps unexpected directory.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error
because it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature
of accepting a symbol was copied by Common Lisp from Zetalisp, which in
turn copied it from Maclisp. The reason Maclisp allowed a symbol here
was that it did not have strings at all. While the feature was removed
from Zetalisp before Common Lisp was defined due to the poor state of
Zetalisp documentation at the time the change was overlooked by the
designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced
into a pathname, why can't a symbol be coerced into a pathname? An
explicit decision was made early in the design of CL not to make all
coercions transitive. For example, symbols coerce to strings (for
string functions), and strings are sequences (and so can be mixed with
other sequence types), but symbols are not sequences.
There is some sentiment for extending COERCE to allow explicit coersion
of STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an
implementation to allow a symbol to be a STREAM (there is no requirement
that STREAM and SYMBOL be disjoint.) While there is some sentiment for
making this requirement in a separate cleanup issue, it would otherwise
prevent both symbol->pathname and stream->pathname to have consistent
meaning.
∂23-Nov-87 1803 CL-Cleanup-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:03:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287374; Mon 23-Nov-87 21:02:17 EST
Date: Mon, 23 Nov 87 21:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-125202-2581@Xerox>
Message-ID: <19871124020219.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I can't get excited about this issue, but the writeup is fine.
∂23-Nov-87 1811 CL-Cleanup-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:10:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287384; Mon 23-Nov-87 21:10:38 EST
Date: Mon, 23 Nov 87 21:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871123-120102-2456@Xerox>
Message-ID: <19871124021039.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks fine.
On the related fill-pointer issue that isn't written up yet, I assume
what we're going to propose is that adjust-array cannot add or remove a
fill-pointer, it can only change the fill-pointer's value. That seems
the consistent extension of what little CLtL says.
∂23-Nov-87 1815 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:15:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287393; Mon 23-Nov-87 21:14:56 EST
Date: Mon, 23 Nov 87 21:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: APPEND-DOTTED (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-122650-2514@Xerox>
Message-ID: <19871124021458.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Bekerly(sp?)
That's Baeckerle I believe.
Typo in Problem Description:
While this specifies the behavior of APPEND when the last argument is
not a list, the behavior when any of the other arguments are not lists.
is not a sentence. Needs "is unspecified" at the end?
Otherwise okay.
∂23-Nov-87 1818 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:18:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287398; Mon 23-Nov-87 21:18:17 EST
Date: Mon, 23 Nov 87 21:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-124211-2551@Xerox>
Message-ID: <19871124021819.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks fine.
∂23-Nov-87 1824 CL-Cleanup-mailer Issue: CONSTANT-SIDE-EFFECTS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:24:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287405; Mon 23-Nov-87 21:23:59 EST
Date: Mon, 23 Nov 87 21:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONSTANT-SIDE-EFFECTS
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871120-114909-1773@Xerox>
Message-ID: <19871124022401.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 20 Nov 87 11:49 PST
From: Masinter.pa@Xerox.COM
Some additional puzzles:
- - - - - -
(defvar a (list 1 2 3 4))
(defconstant b a)
(setf (car a) 4)
I don't know what I think about this one, it's real nasty. The first
paragraph on CLtL p.69 probably says that defconstant is not allowed
to make a fresh copy of the list; if true, this is code certainly an
error, although the error might be rather difficult to detect in any
practical implementation.
- - - - - -
(nconc `(,x 5 6 7) y)
I prefer to call this an error, on the grounds that ` should be as much
like ' as possible. For extra help in thinking about this, try
(nconc `(5 6 7) y)
∂23-Nov-87 1825 CL-Cleanup-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:25:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287408; Mon 23-Nov-87 21:25:16 EST
Date: Mon, 23 Nov 87 21:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871123-132257-2668@Xerox>
Message-ID: <19871124022518.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks fine.
∂23-Nov-87 1830 CL-Cleanup-mailer Issue: PATHNAME-SYMBOL (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:30:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287416; Mon 23-Nov-87 21:30:14 EST
Date: Mon, 23 Nov 87 21:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-174007-3050@Xerox>
Message-ID: <19871124023017.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Typo:
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their
file or filename argument, and that DIRECTORY does not allow a symbol
for its pathname argument. This is implied by the respective
descriptions of those functions in CLtL, but as explicitly stated.
The word "as" in the last line is probably supposed to be "not".
Otherwise this looks fine.
∂23-Nov-87 1839 CL-Cleanup-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:39:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 287428; 23 Nov 87 21:39:27 EST
Date: Mon, 23 Nov 87 21:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871123-140249-2744@Xerox>
Message-ID: <19871124023928.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks fine. Simple and elegant.
∂24-Nov-87 1244 CL-Cleanup-mailer Issue: KEYWORD-KEYWORDS (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 87 12:43:49 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 288190; Tue 24-Nov-87 15:43:30 EST
Date: Tue, 24 Nov 87 15:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-KEYWORDS (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871124154316.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm not passionate about the following proposal, so don't panic if you
don't happen to like it. I'm not prepared to fight to the death on it.
But it is a serious proposal and I wanted to at least get it off my desk
and into the official record...
----------
Issue: KEYWORD-KEYWORDS
References: LAMBDA (p59), DEFUN (p67), DEFMACRO (p145), FLET (p113),
MACROLET (p113), DEFSETF (p102), FUNCTION declaration (p159),
:CONSTRUCTOR option to DEFSTRUCT (pp315-316).
Category: CHANGE
Edit history: 24-Nov-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Anyone who shadows LOAD, COMPILE, or EVAL is obliged to shadow
EVAL-WHEN (although in practice many people forget and this crops up
as a bug later on). This issue comes up a lot in embedded systems,
such as Scheme which use stylized loaders, compilers, or evaluators.
The lambda-list keywords are not symbols on the keyword package.
KEYWORDP is not true of them. Names that begin with & are generally
not usable as variables because many compilers worry that names
which begin with & but are not on LAMBDA-LIST-KEYWORDS might be
unsupported `keywords' or mis-spellings of supported `keywords'.
Proposal (LAMBDA-LIST-KEYWORDS:KEYWORD):
Change EVAL-WHEN to use :EVAL, :LOAD, and :COMPILE rather than
EVAL, LOAD, and COMPILE.
Change LAMBDA and the various macros which use &OPTIONAL, &REST, &AUX,
&BODY, &WHOLE, &ENVIRONMENT, &KEY, and &ALLOW-OTHER-KEYS to :OPTIONAL
to use :OPTIONAL, :REST, :AUX, :BODY, :WHOLE, :ENVIRONMENT, :KEY, and
:ALLOW-OTHER-KEYS instead.
eg,
(DEFUN FOO (W :OPTIONAL (X 3) (Y 4) :REST Z :KEY A B C)
...)
Rationale:
Symbols in the keyword package are already unavailable as variable names
because they must be bound to themselves.
This change would make the term keyword would be used to denote one fewer
concept in the language.
Current Practice:
No one does this.
Adoption Cost:
Recognizing these ":" names instead of "&" names would be trivial, though
would involve numerous small changes throughout most systems, including
changes to the parts of the system which are written in Lisp and which use
the old keywords in their definitions.
The `keywords' now in use could continue to be supported by any vendors
for a while. Such a deviation would technically make an implementation not
conform to the standard, but in practice would not be likely to cause any
problems if phased out within a reasonable period of time.
Benefits:
This would make shadowing of EVAL, COMPILE, and LOAD not have a surprising
effect on EVAL-WHEN.
Although this would not completely fix uses of the word keyword throughout
the langauge, it would make the use of the term `keyword' considerably more
regular.
The "&" character is freed for possible other uses. There is currently an
occassional desire to use it as a readmacro character, but the need to have
access to these keywords tends to make that impractical because no one wants
to write: (defun foo (x \&optional y) ...).
Non-Benefits:
The change is cosmetic. It arguably adds no power to the language and might
therefore be accused of being gratuitous.
Conversion Cost:
Users would have to change a lot of code in a relatively superficial way,
but probably a trivial Query Replace operation would suffice with high
reliability.
Aesthetics:
Usage of the term `keyword' is simplified, arguably improving learnability
and simplifying some documentation.
People might differ on whether they think programs will look better.
Discussion:
Pitman wanted this change back when CLtL was not yet published but
suggested it "too late" for it to be considered. People ask about this
issue from time to time, and this is the appropriate time for it to be
reconsidered, even if only to be found to be a gratuitous change. Pitman
thinks the change would be nice, but is sensitive to the fact that some
may balk at the cost of the number of trivial changes it would require.
Less extreme variations of this proposal might include accepting :keywords
in addition to rather than instead of &keywords and/or allowing EVAL-WHEN
to use STRING-EQUAL rather than EQL to find its `keywords'.
∂24-Nov-87 1337 CL-Cleanup-mailer Re: Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 87 13:37:10 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA04136; Tue, 24 Nov 87 16:40:58 EST
Message-Id: <8711242140.AA04136@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DEFVAR-DOCUMENTATION (Version 2)
In-Reply-To: Your message of 23 Nov 87 13:22:00 -0800.
<871123-132257-2668@Xerox>
Date: Tue, 24 Nov 87 16:40:52 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
You might also note that literal documentation strings can serve as
maintainer's documentation in lieu of some comments. While this is
not a sufficient reason for the ruling on its own, it does help make
Common Lisp programs more maintainable.
∂24-Nov-87 1920 CL-Cleanup-mailer Issue: KEYWORD-KEYWORDS (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 19:20:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 24 Nov 87 22:19:53-EST
Date: Tue, 24 Nov 1987 22:19 EST
Message-ID: <FAHLMAN.12353310227.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-KEYWORDS (Version 1)
In-reply-to: Msg of 24 Nov 1987 15:43-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
If we were doing a new language from scratch, I think that both
EVAL-WHEN and the lambda-list format would be done very differently from
the way they were done in Common Lisp, causing this whole issue to
disappear. As it is, I think that it would be a big mistake to totally
change the look of the language and the syntax used by practically
*every* Common Lisp program in existence just to achieve the modest
cosmetic benefits you cite.
-- Scott
∂25-Nov-87 0917 CL-Cleanup-mailer Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Nov 87 09:17:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 NOV 87 09:13:48 PST
Date: 25 Nov 87 09:12 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of
Wed, 25 Nov 87 09:45:03 MST
To: sandra%orion@cs.utah.edu, RWK@YUKON.SCRC.Symbolics.COM,
franz!layer@ucbarpa.berkeley.edu, sandra%orien@cs.utah.edu,
Ghenis.pasa@Xerox.COM, EWeaver.PA@Xerox.COM, Ram@C.CS.CMU.EDU
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871125-091348-1853@Xerox>
Sandra sent me a list of possible options of what your working group
might do on the issue of pathnames.
I had imagined a bottom-up approach, going from current practice in
various systems (especially the networked systems) that try to deal
simultaneously with multiple operating systems, into something that
could be generally adopted.
Of the options that Sandra sent me, these are my preferences:
(1) Try to establish and document what constitutes portable usage,
independent of additional restrictions or new functionality.
(2) Try to specify a portable extension for dealing with hierarchical
file systems (such as provided by Unix, VMS, Tops-20, Symbolics,
MS-DOS, Macintosh, Xerox), and pathnames that specify directories
instead of files
(3) For various common operating systems, specify exactly what can go
into each pathname component. Clarify things like whether the square
brackets that surround a directory specification in VMS filename syntax
are actually part of the string stored in the directory field or not,
whether the "." that usually separates the name and type fields is part
of one or the other or neither, etc.
(4) Specify what MAKE-PATHNAME should do if it can't build a valid
pathname from the arguments it gets. (PARSE-NAMESTRING either signals
an error or returns NIL, depending on the value of the :JUNK-ALLOWED
argument.)
(5) Clear up what should happen if the operating system just doesn't
support the notion of one or another of the pathname components, such as
versions on Unix or directories on CTSS. Also come up with some way of
dealing with case (in)sensitivity, maximum lengths on the various
fields, and what characters are valid in filenames. (Versions are
particularly important in the context of OPEN.)
I don't like this one, but only because no-one has convinced me of its
usefulness and
I don't like adding useless features:
(6) Add an optional argument to TRUENAME to indicate that you want
translation only, without checking to see if the file really exists or
not.
Sandra sent a suggestion about removing requirements on (PATHNAME
<sybmol>), but I think the sentiment is to remove the automatic coercion
of symbols into pathnames entirely, so that (PATHNAME <symbol>) is an
error (see issue PATHNAME-SYMBOL).
∂25-Nov-87 1547 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Nov 87 15:47:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 NOV 87 15:47:00 PST
Date: 25 Nov 87 15:46 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-LEXICAL (Version 5)
In-reply-to: Masinter.pa's message of 14 Nov 87 21:04 PST
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Message-ID: <871125-154700-2532@Xerox>
What I remember about the discussion in Denver is fading quickly.
I remember that there's a problem with CONSTANT, in that (DEFCONSTANT X
...) can't expand into (PROCLAIM '(CONSTANT X)) followed by setting X
because it would be an error to set it after it was proclaimed constant,
and it can't do the set first and the proclaim second, because it is an
error to set it if it isn't declared, and you can't first proclaim it
global and then constant because it is an error to change the
proclaimation of a variable.
There was a lot of confusion about the proposal because people didn't
understand GLOBAL; in particular, there was lots of grumbling about the
example, where even though a variable was proclaimed lexical and there
was a lexical reference to it, a SPECIAL binding could still overwrite
the definition.
There was a lot of grumbling that the notion of "global LEXICAL" was a
contradiction, because "lexical" usually meant "limited scope" and that
you could tell when the scope started and ended, but in the case of what
we were calling global lexical, there was no way to terminate the scope.
There was some mumbling about making a "file" have a global lexical
scope or some way of terminating a global lexical scope at the "top
level" etc. etc., but it was all at the level of mumble.
Frankly, I think these are pretty serious problems...
Comments?
∂25-Nov-87 1745 CL-Cleanup-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Nov 87 17:45:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 NOV 87 17:45:10 PST
Date: 25 Nov 87 17:44 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU, peck@Sun.COM
cc: Masinter.pa@Xerox.COM
Message-ID: <871125-174510-2657@Xerox>
This version attempts to clean up the previous one. I've tried to
address the various remarks and special cases by cleaning up the
description. I think the prose is still turgid and there are likely the
usual typos, but... Comments please.
I think this is my last message until after Thanksgiving. I hope you
will have (or have had) a pleasant one.
If you can't tell, I've been going thru the open issues alphabetically.
Feel free to respond to any of the open issues, of course.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Issue SETF-FUNCTION-VS-MACRO.
Category: CLARIFICATION
Edit History: Version 1, 15-Oct-87, Jeff Peck
Version 2, 23-Oct-87, Larry Masinter
Version 3, 8-Nov-87, David Moon
Version 4, 14-Nov-87, Larry Masinter
Version 5, 25-Nov-87, Larry Masinter
Problem Description:
In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1)
should be evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Macros that manipulate generalized variables must guarantee the
`obvious' semantics: subforms of generalized-variable references are
evaluated ... in exactly the same order as they appear in the *source*
program. The expansion of these macros must consist of code that follows
these rules or has the same effect as such code. This is accomplished
by introducing temporary variables bound to the subforms of the
reference."
This paragraph and a discussion of SETF on the previous pages may also
be interpreted as requiring that *all* subforms of such macro calls
should be evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice while
PUSH takes care to evaluate them only once."
Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form. Should the PUSH form have primacy over
the obvious SETF form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or
only those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized
variables, e.g., PUSHNEW, INCF, DECF, and those defined with
DEFINE-MODIFY-MACRO.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
This proposal is hard to state, although the intent is fairly clear:
evalution proceeds from left to right whenever possible. The
left-to-right rule does not remove the obligation on writers of macros
and define-setf-method to ensure left-to-right order, however.
In this proposal, a form is something whose syntactic use is such that
it will be evaluated. A "subform" means a form that is nested inside
another form -- not any object nested inside a form regardless of
syntactic context.
(1) The evaluation ordering of subforms within a generalized variable
reference is determined by the order specified by the second value
returned by GET-SETF-METHOD. For all predefined generalized variable
references (GETF, LDB), this order of evaluation is exactly
left-to-right. When a generalized variable reference is derived from a
macro expansion, this rule is applied *after* the macro is expanded to
find the appropriate generalized variable reference.
This is intended to make it clear that if the user writes a DEFMACRO or
DEFINE-SETF-METHOD that doesn't preserve order, the the order specified
in the user's code holds; e.g., given
(DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
will evaluate <place2> first and then <place1> because that is the order
they are evaluated in the macro expansion.
(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW,
GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those
defined with DEFINE-MODIFY-MACRO) the subforms of the macro call are
evaluated exactly once in left to right order, with the subforms of the
generalized variable references evaluted in the order specified in (1).
PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP
evaluate all subforms before modifying any of the generalized variable
locations. SETF (in the case when the SETF macro has more than two
arguments) performs its operation on each pair in sequence, i.e., in
(SETF <place1> <value1> <place2> <value2> ...), the subforms of <place1>
and <value1> are evaluated, the location specified by <place1> is
modified to contain the value returned by <value1>, and then the rest of
the SETF form is processed in a like manner.
(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the
generalized variable reference are evaluted once as in (1), but may be
evaluted again if the type check files in the case of CHECK-TYPE or none
of the cases hold in CTYPECASE and CCASE.
(4) For the macro ASSERT, the order of evaluation of the generalized
variable references is not specified.
(Rules 2, 3 and 4 cover all macros defined in Common Lisp that
manupulate generalized variable references.)
Examples:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
Under this proposal, this would be required to print 12 and not 21.
(LET (X)
(PUSH (SETQ X (LIST 'A))
(CAR (SETQ X (LIST 'B))))
X)
; the PUSH first evalutes (SETQ X (LIST 'A)) => (A)
; then evaluates (SETQ X (LIST 'B)) => (B)
; then modifies the CAR of (this latest value) to be ((A) . B).
; The result is (((A) . B)).
Documentation impact:
PUSH should more appropriately be described as:
"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item
Place)) except that the subforms of Place are evaluated only once, and
Item is evaluated before Place."
The phase "subforms of the reference" which appears several times in
CLtL should be made more specific to be "subforms of the macro call,"
referring to the entire form that calls the generalized-variable
manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended
definition of "obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In
the form (PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place
then Item. Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Cost to implementors:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost to users:
No currently portable program should be affected. However, this is a
minor incompatible change for some implementations. No serious
performance impact is expected; while some macro expansions may appear
to be more verbose, most compilers deal reasonably with the required
order of evaluation.
Benefits:
The implementation and semantics of PUSH become more well specified.
This removes a source of non-portability, abeit likely rare.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this
clarification ensures consistency across the language.
Discussion:
This seems to be the intent of most of the relevant language in CLtL.
For example, the second to last paragraph on page 99
"As an example of these semantic rules, in the generalized-variable
reference (setf reference value), the value form must be evaluated
after all the subforms of the reference because the value form
appears to the right of them."
makes it clear that in this context the phrase "generalized-variable
reference" was meant to refer to the entire macro call, not just the
Place, and that order of evaluation rules are not limited to subforms of
Places. We hope the specification should adopt more consistent
terminology.
Note that DEFINE-SETF-METHOD is immune to the exception specified about
DEFMACRO and DEFINE-SETF-METHOD, because since CLtL p.103 says about
DEFINE-SETF-METHOD:
"This binding permits the body forms to be written without regard for
order-of-evaluation issues."
∂25-Nov-87 1750 CL-Cleanup-mailer Issue status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Nov 87 17:49:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 NOV 87 17:49:35 PST
Date: 25 Nov 87 17:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue status
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <871125-174935-2663@Xerox>
This isn't quite up to date as I've missed a few, but I thought I should
go ahead and send it out if you're keeping a score card... I think we
have some new members of the distribution list as of the last week or
so...
- Proposal format (Version 13, 20-Nov-87)
Version 12 Released to X3J13
? Ready for release ?
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
? Remove displaced arrays ?
Ready for release
- APPEND-DOTTED (Version 4, 23-Nov-87)
(What happens to CDR of last CONS? in other
than last arg?)
? Ready for release?
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
? Ready for release?
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
? Ready for release?
- DECLARE-MACROS (Version 2, 9-Nov-87)
(Disallow macros expanding into declarations.)
Needs more examples of alternatives
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
? Ready for release
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
(Can DO-SYMBOLS see the same symbol twice?)
? ready for release
- FORMAT-COLON-UPARROW-SCOPE (not yet submitted)
(what iteration does ~:↑ exit from?)
Common-Lisp mailing list discussion Nov 87
Steele will submit
- FUNCTION-TYPE (Version 7,8, 9-Nov-87, 14-Nov-87)
(Change definition of FUNCTIONP, function type ...)
Discussed at X3J13, new proposal due.
Not eady for release
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Ready for release
- KEYWORD-KEYWORDS (Version 1)
- LOAD-TIME-EVAL (Version 3, 11-Nov-87)
(New function/macro/special form for evaluation
when compiled file is loaded?)
Not ready for release
- PATHNAME-SYMBOL (Version 3, 23-OCT-87)
(Do symbols automaticly coerce to pathnames?)
? Ready for release?
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
Serious problems ... cut down proposal?
- PUSH-EVALUATION-ORDER (Version 5, 25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not ready for release
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
Not ready for release
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
Ready for release
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
? Ready for release?
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
? Ready for release?
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87)
(What does SHADOW do if symbol is already there?)
Ready for release
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(What package are *FEATURES* in?)
Ready for release
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
? Ready for release?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
Not ready for release
Need volunteer:
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
RAM?
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (not yet submitted)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
Discussed at length, but no formal proposals.
- DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
"Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled
and then disassembled, but the resulting compiled definition
does not replace the interpreted one as the symbol's function
definition."
Pierson@MultiMax.ARPA volunteered to submit.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Steele? will write up.
- FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted)
(allow &rest <type> in function types to refer to element
type rather than list)
Disscussed at length in the past.
sandra%orion@cs.utah.edu.
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
Mail from Moon 16-Jun.
cf SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- REDUCE-ARGUMENT-EXTRACTION (no proposal)
Mail on COMMON-LISP about adding a new keyword argument
to REDUCE to extract the appropriate value.
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file)
(P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must
be initially bound to synonym streams to *TERMINAL-IO*; demote
this to the level of an implementation suggestion. This is to
allow flexibility of implementation, for example to allow UNIX
redirection to win."
Need volunteer to submit
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
Hold: Awaiting action from another committee.
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal'
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Awaiting error proposal.
- IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions
- IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Awaiting error proposal
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
Tabled: Awaiting new proposal.
- ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87)
(ADJUST-ARRAY on non-adjustable arrays returns copy)
extend COPY-ARRAY instead?
Tabled until resubmitted
- DEFINITION-FUNCTIONS (no formal proposal)
(Extensions for documentation-type for delete-definition
for type FUNCTION, VARIABLE, TYPE. )
Rough draft mailed 9-Oct-87.
JonL may mail something.
- EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE
Wait on FUNCTION-TYPE, LOAD-TIME-EVAL
Propose #., #, changes independently.
- EXPORT-COORDINATION (no formal proposal)
Add new macros for defining, export at same time
Too many interactions with package system
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- OPEN-KEYWORDS (Version 1, 17-Jul-87)
Discussion 9-Nov-87
Questionable; needs stronger justification.
Tabled until resubmitted.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
Doesn't really solve our problems?
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
Table until resubmitted
Approved: No further action pending.
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87.
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Approved voice vote X3J13/Nov87
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 no objects X3J13/Nov87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 no objections X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 no objections X3J13/Nov 87
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
∂27-Nov-87 0751 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Nov 87 07:51:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 289858; Fri 27-Nov-87 10:50:43 EST
Date: Fri, 27 Nov 87 10:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PROCLAIM-LEXICAL (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
In-Reply-To: <871125-154700-2532@Xerox>
Message-ID: <19871127155030.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 25 Nov 87 15:46 PST
From: Masinter.pa@Xerox.COM
There was a lot of grumbling that the notion of "global LEXICAL" was a
contradiction....
As I recall, the original motivation for making a proposal here was
popular demand for a notion of "global LEXICAL" in the language. The
evolution of the proposal was then driven by a desire to straighten out
various inconsistencies, but may have lead to introducing more
inconsistencies or complexities, a process to which I am afraid I have
contributed. If there is some kind of concensus that no one wants
"global LEXICAL" anyway, maybe we ought to call the whole thing off? I
still think Common Lisp has some confusion here that would be worth
straightening out, but certainly there are other areas we could be
cleaning up instead.